"getaddrinfo EAI_AGAIN" on CI

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 https://github.com/backstage/backstage/pull/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.

[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.