[Regression 13.0.2] Persistent interceptors using request

[Treyone]

Behavior
We are using persistent interceptors with scope.persist(). These interceptors have a reply function thats uses the req attribute to read request headers. Our test cases run multiple requests in parallel (using Promise.all in the client code), with different header values.

Up to version 13.0.1, this cas working fine:

• request 1 -> header value A
• request 2 -> header value B
• request 3 -> header value C

Since version 13.0.2

• request 1 -> header value C
• request 2 -> header value C
• request 3 -> header value C

This seems to be due to the fact that since 3b24821, the interceptor.req is now set in intercepted_request_router.js, not in playback_interceptor.js anymore. as other requests arrived in the meantime, the req attribute is overwritten and all reply functions get the last value.
The req arg of playbackFunction still has the good values right before calling the reply function though, here:

nock/lib/playback_interceptor.js

Line 169 in 3b24821

if (interceptor.fullReplyFunction) {

Possible solution

As the designed commit is itself fixing a bug, I'm not confident implementing a fix. I could see 2 options:

• don't set the req attribute in the router but bring it back to the interceptor playback
• pass the req in a separate argument, not as an interceptor attribute

How to reproduce the issue

See above.

Does the bug have a test case?

No. It could be a new test in test_intercept_parallel.js, where the reply is a function that uses req.headers.

[mastermatt]

Thanks, I'm taking a look and writing a failing test now.

[Treyone]

Great, thanks for having a look so quickly !

[ndelvalle]

I'm also seeing this behavior in version 13.0.1

[github-actions]

🎉 This issue has been resolved in version 13.0.4 🎉

The release is available on:

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

Your semantic-release bot 📦🚀