In 11.0.0-beta.30, when no body is provided `.filteringRequestBody()` no longer has any effect

I have a test case that failed in IcedFrisby in 11.0.0-beta.30. I’ve confirmed that in 11.0.0-beta.29 the test case passes which means this changed in #1632.

I am pretty sure this is a bug, though it’s a slightly awkward / broad test case which I haven’t yet narrowed down to a specific behavior of nock.

it('should fail with the last error when every retry errors out', async function() {
  const retryCount = 4
  let actualRequestCount = 0

  const scope = nock('http://example.test')
    .filteringRequestBody(body => {
      actualRequestCount += 1
      return body
    })
    .get('/just-dont-come-back-2')
    .delayBody(50)
    .times(retryCount + 1)
    .replyWithError(
      Error('This could be a network error or an internal error')
    )

  await expect(
    frisby
      .create(this.test.title)
      .get('http://example.test/just-dont-come-back-2')
      .retry(retryCount, 0)
      .run()
  ).to.be.rejectedWith(
    Error,
    'This could be a network error or an internal error'
  )

  expect(actualRequestCount).to.equal(retryCount + 1)
  scope.done()
})

In 11.0.0-beta.29, the filteringRequestBody callback runs 5 times and the expect(actualRequestCount).to.equal(retryCount + 1) assertion passes. (expect(5).to.equal(5)).

In 11.0.0-beta.30, the filteringRequestBody callback does not run at all, and the assertion fails (expect(0).to.equal(5)).

[mastermatt]

The ‘replied’ event does not currently fire when using replyWithError. As for the “should it?”… the current behavior of that event is that it denotes when the IncomingMessage has been passed all the data chunks and is “complete”. With that mindset, it make sense that replyWithError does not emit the replied event as the error is fired on the request object and the response is never provided any data. I would probably vote to leave that event as-is. An event could be added that denotes an Interceptor was consumed, but I think that would end up being 1:1 with the existing request event.

[paulmelnikow]

Seems reasonable! Probably it’s a good idea to clarify in the API docs when those events fire, though we can save that for another day.