Interceptors don't match when used with different order "when using filteringScope option"

[salmanm]

What is the expected behavior?

Interceptors should match correct request even when using filteringScope option

What is the actual behavior?

Typically interceptors work in any order. However, when using filteringScope option, they misbehave and don't match.

How to reproduce the issue

Take the following for example.

  nock('http://some.test', {
    filteringScope: scope => true,
  })
  .get('/path1?query=1')
  .reply(200, 'response for path1/query1')
  .get('/path2?query=2')
  .reply(200, 'response for path2/query2')

Here, if I make the request for /path2?query=2 first, it fails. Because the filteringScope returns true and it tries to match the path of /path2?query=2 against the first interceptor.

Possible solution

Here we return interceptors as soon as we find the one with filteringScope option. By doing this, we skip setting interceptor.__nock_filteredScope on the "actual" interceptor that should have been matched. Hence, if we return after the inner loop is over, then that should work.

Instead of RunKit, I'm opening a PR with two test cases to demonstrate the problem.

Having problem producing a test case? Try and ask the community for help. If the test case cannot be reproduced, the Nock community might not be able to help you.

Does the bug have a test case?

Versions

Software	Version(s)
Nock	latest
Node	10
TypeScript	-

[paulmelnikow]

Hi, thanks for the report and the PRR!

I think this is related to the failing tests I added in #1720, right?

[salmanm]

O yes, didn't notice that PR. Yes looks like its one of those cases.

[nockbot]

🎉 This issue has been resolved in version 11.7.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀