"getaddrinfo EAI_AGAIN" on CI

[benjdlambert]

Prerequisites

• I confirm my issue is not in the opened issues
• I confirm the Frequently Asked Questions didn't contain the answer to my issue

Environment check

• I'm using the latest msw version
• I'm using Node.js version 14 or higher

Node.js version

14.x / 16.x

Reproduction repository

https://github.com/benjdlambert/msw-example-repo

Reproduction steps

Unable to reproduce this locally, think some form of race condition but it happens in our CI which is github actions running ubuntu-latest, this has been known to pass using macos-latest.

https://github.com/benjdlambert/msw-example-repo/runs/6130933244?check_suite_focus=true

Is a failure run, notice the logs how the mock is not stable under run test .

Fetch 90 failed with FetchError: request to https://nono-nononono-nononono-nono-theres-no-host/ failed, reason: getaddrinfo EAI_AGAIN nono-nononono-nononono-nono-theres-no-host
        at NodeClientRequest.<anonymous> (/home/runner/work/msw-example-repo/msw-example-repo/node_modules/node-fetch/lib/index.js:[14](https://github.com/benjdlambert/msw-example-repo/runs/6130933244?check_suite_focus=true#step:6:14)91:11)
        at NodeClientRequest.emit (events.js:400:28)
        at NodeClientRequest.Object.<anonymous>.NodeClientRequest.emit (/home/runner/work/msw-example-repo/msw-example-repo/node_modules/@mswjs/interceptors/src/interceptors/ClientRequest/NodeClientRequest.ts:284:22)
        at TLSSocket.socketErrorListener (_http_client.js:475:9)
        at TLSSocket.emit (events.js:400:28)
        at emitErrorNT (internal/streams/destroy.js:106:8)
        at emitErrorCloseNT (internal/streams/destroy.js:74:3)
        at processTicksAndRejections (internal/process/task_queues.js:82:21)

      at test.test.ts:56:17

  console.log
    Fetch 98 failed with FetchError: request to https://nono-nononono-nononono-nono-theres-no-host/ failed, reason: getaddrinfo EAI_AGAIN nono-nononono-nononono-nono-theres-no-host
        at NodeClientRequest.<anonymous> (/home/runner/work/msw-example-repo/msw-example-repo/node_modules/node-fetch/lib/index.js:1491:11)
        at NodeClientRequest.emit (events.js:400:28)
        at NodeClientRequest.Object.<anonymous>.NodeClientRequest.emit (/home/runner/work/msw-example-repo/msw-example-repo/node_modules/@mswjs/interceptors/src/interceptors/ClientRequest/NodeClientRequest.ts:284:22)
        at TLSSocket.socketErrorListener (_http_client.js:475:9)
        at TLSSocket.emit (events.js:400:28)
        at emitErrorNT (internal/streams/destroy.js:106:8)
        at emitErrorCloseNT (internal/streams/destroy.js:74:3)
        at processTicksAndRejections (internal/process/task_queues.js:82:21)

      at test.test.ts:56:[17](https://github.com/benjdlambert/msw-example-repo/runs/6130933244?check_suite_focus=true#step:6:17)

Current behavior

We have recently upgraded from 0.35 to latest in this PR backstage/backstage#10589 and noticed that theres some failures for some tests. Been digging in this for the last few days to work out what is going on and wether it's something that we own that we could fix.

Looks like when setting up the mocks that the mock is not stable, and repeated requests to the mocked endpoint will sometimes yield the mocked data, and sometimes in our case it will try to make the request to the origin. Which for the purpose of the test case that I have reported is some unknown DNS and that's the error we get.

As you can see in the simple reproduction example that I have provided, we setup a mock, and then in the test we repeatedly call that mocked endpoint and get some DNS resolution errors which happen sporadically throughout the test run. This is of course an extreme example hitting it many times, but it happens when it's not called under load and causes flakey test failures.

Interestingly running the same tests under macos-latest as the agent in CI seemed to work. So not sure if some slowness or fastness is one of the runners is mitigating this, and maybe it's a race condition.

Haven't had much time to dig into the source code, but it looks like this could be something that's been changed or added in the versions after 0.35 to now as our other test suite is stable.

Expected behavior

The fetch request returns the mock data all the time, rather than sometimes trying to bypass the mocked request and actually call out to the original origin.

[kettanaito]

Hey, @benjdlambert. Thanks for reporting this.

I suspect the issue is related to the new interceptor we've introduced in 0.38.0 if I'm not mistaken (read more here). We do make actual connections when intercepting requests now but we treat those connections as an implementation detail of the interceptor. We should silence any connection-related errors to prevent false negatives during mocks when requesting non-existing endpoints (exactly what you're doing). Apparently, that error collection/replay fails in your scenario.

Thank you for preparing the reproduction repository! I will look into it once I have a minute.

[benjdlambert]

Great - yep that sounds like the likely cause here. I think it's fair to assume it's been a bit of a head scratcher for us to try and work out why it only fails in some situations and not others, so any help would be much appreciated! Thanks!

[kettanaito]

We are certainly not accounting for the EAI_AGAIN errors in the suppressed errors list of the interceptor. I think we should add that. Also, I have a suspicion to believe that while we suppress connection errors on the ClientRequest surface, the socket instance it uses still receives and propagates errors to the underlying clients (may be the case for clients that listen for socket errors directly instead of ClientRequest errors).

[kettanaito]

I'm going to add the EAI_AGAIN error to the list of the suppressed errors in our ClientRequest interceptor. This should silence that error and first attempt to resolve the request against mocks (mswjs/interceptors#243). The fix will propagate with the next release of @mswjs/interceptors and you should see a comment in this thread about it.

[benjdlambert]

Nice! Sorry for the delay, i've been off for a few days. Seen that it's been released under 0.16, which doesn't meet the semver match in msw yet, when can we expect that version range to change? Thanks again!

[kettanaito]

Hey, @benjdlambert. I'm currently working on updating the Interceptors dependency in MSW. There's been quite a few breaking changes, so it takes time to fully migrate. Cannot give any estimates as I approach this in my free time.

[benjdlambert]

No probs at all! Please let us know if there's anyway I can help out 🙏

[kettanaito]

Released: v0.42.0 🎉

This has been released in v0.42.0!

• 📄 Release notes
• 📦 npm package

Make sure to always update to the latest version (npm i msw@latest) to get the newest features and bug fixes.

---

Predictable release automation by @ossjs/release.