Msw: Error: Error: connect ECONNREFUSED 127.0.0.1:80

Created on 7 Dec 2020  路  13Comments  路  Source: mswjs/msw

Environment

| Name | Version |
| ---- | ------- |
| msw | 0.21.3 |
| node | 12.19.0 |
| OS | MacOS |

Request handlers

```jsimport { setupServer } from "msw/node";
import { rest } from "msw";
import check1result from "./check1result";
import check2result from "./check2result";

function check1(queryParams: URLSearchParams): boolean {
return true;
}

function check2(queryParams: URLSearchParams): boolean {
return true;
}

const requestHandler = [
rest.get("/api/resources", (req, res, ctx) => {
let json;
const queryParams = req.url.searchParams;

if (check1(queryParams)) {
  json = ctx.json(check1result);
} else if (check2(queryParams)) {
  json = ctx.json(check2result);
}
{
  json = ctx.json([]);
}

return res(ctx.delay(0), ctx.status(200), json);

}),
];

const orderReturnMockServer = setupServer(...requestHandler);

// mws api server mock initialization
beforeAll(() =>
orderReturnMockServer.listen({
onUnhandledRequest: "error",
})
);
afterAll(() => orderReturnMockServer.close());

describe('describe', () => {
test('test1', () => {
networkCall()
})
test('test2', () => {
networkCall()
})
})


## Actual request

```js
// Example of making a request. Provide your code here.
fetch('???').then((res) => res.json())

Current behavior

A lot of Error: Error: connect ECONNREFUSED 127.0.0.1:80 in the console logs when running my tests. But the tests
pass most of the time. Sometimes there's failures - for example timeouts. Not sure if it's related to this though, just
saying.

Expected behavior

No errors about connection refused in the console logs - as it looks like something's wrong, but I don't know what's wrong
and the tests pass too. :/

Screenshots

I'll paste some logs instead

console.error node_modules/@testing-library/react/dist/act-compat.js:52
      Error: Error: connect ECONNREFUSED 127.0.0.1:80
          at Object.dispatchError (/Users/karuppiahn/projects/deda-group/S-OMS/s-oms-ui/node_modules/jsdom/lib/jsdom/living/xhr/xhr-utils.js:62:19)
          at Request.<anonymous> (/Users/karuppiahn/projects/deda-group/S-OMS/s-oms-ui/node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:654:18)
          at Request.emit (events.js:326:22)
          at Request.onRequestError (/Users/karuppiahn/projects/deda-group/S-OMS/s-oms-ui/node_modules/request/request.js:877:8)
          at ClientRequestOverride.emit (events.js:314:20)
          at ClientRequest.<anonymous> (/Users/karuppiahn/projects/deda-group/S-OMS/s-oms-ui/node_modules/node-request-interceptor/src/interceptors/ClientRequest/ClientRequestOverride.ts:292:14)
          at ClientRequest.emit (events.js:314:20)
          at Socket.socketErrorListener (_http_client.js:428:9)
          at Socket.emit (events.js:314:20)
          at emitErrorNT (internal/streams/destroy.js:92:8) undefined


console.error node_modules/jsdom/lib/jsdom/virtual-console.js:29
      Error: Error: connect ECONNREFUSED 127.0.0.1:80
          at Object.dispatchError (/Users/karuppiahn/projects/deda-group/S-OMS/s-oms-ui/node_modules/jsdom/lib/jsdom/living/xhr/xhr-utils.js:62:19)
          at Request.<anonymous> (/Users/karuppiahn/projects/deda-group/S-OMS/s-oms-ui/node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:654:18)
          at Request.emit (events.js:326:22)
          at Request.onRequestError (/Users/karuppiahn/projects/deda-group/S-OMS/s-oms-ui/node_modules/request/request.js:877:8)
          at ClientRequestOverride.emit (events.js:314:20)
          at ClientRequest.<anonymous> (/Users/karuppiahn/projects/deda-group/S-OMS/s-oms-ui/node_modules/node-request-interceptor/src/interceptors/ClientRequest/ClientRequestOverride.ts:292:14)
          at ClientRequest.emit (events.js:314:20)
          at Socket.socketErrorListener (_http_client.js:428:9)
          at Socket.emit (events.js:314:20)
          at emitErrorNT (internal/streams/destroy.js:92:8) undefined


console.error node_modules/jsdom/lib/jsdom/virtual-console.js:29
      Error: Error: connect ECONNREFUSED 127.0.0.1:80
          at Object.dispatchError (/Users/karuppiahn/projects/deda-group/S-OMS/s-oms-ui/node_modules/jsdom/lib/jsdom/living/xhr/xhr-utils.js:62:19)
          at Request.<anonymous> (/Users/karuppiahn/projects/deda-group/S-OMS/s-oms-ui/node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:654:18)
          at Request.emit (events.js:326:22)
          at Request.onRequestError (/Users/karuppiahn/projects/deda-group/S-OMS/s-oms-ui/node_modules/request/request.js:877:8)
          at ClientRequestOverride.emit (events.js:314:20)
          at ClientRequest.<anonymous> (/Users/karuppiahn/projects/deda-group/S-OMS/s-oms-ui/node_modules/node-request-interceptor/src/interceptors/ClientRequest/ClientRequestOverride.ts:292:14)
          at ClientRequest.emit (events.js:314:20)
          at Socket.socketErrorListener (_http_client.js:428:9)
          at Socket.emit (events.js:314:20)
          at emitErrorNT (internal/streams/destroy.js:92:8) undefined

Something to add is, we do have some tests that get rid of components abruptly when they are in the middle of a fetch call (my assumption), which leads to a lot of the below logs

console.error node_modules/@testing-library/react/dist/act-compat.js:52
      Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.
          in Orders (at Orders.test.tsx:121)
          in ThemeProvider (at Orders.test.tsx:120)
          in IntlProvider (at Orders.test.tsx:119)
          in Router (at Orders.test.tsx:118)
          in KeycloakProvider (at keycloak_mock_provider.tsx:46)
          in MockedKeycloakProvider (at Orders.test.tsx:117)
bug node

Most helpful comment

Just a question, do you have a single instance of setupServer? or you have more test modules with different servers?

All 13 comments

@karuppiah7890 In your situation, I would have updated MSW as well as node, could you try that :+1:?

Also, this does not seem to be related to MSW, or at least from the screenshots, if I am not mistaken :thinking:

Ah okay. It's weird yarn upgrade didn't upgrade it. I thought that would have done it.

And the logs mention about a connection and about node request interceptor. But yeah, I'll dig in and get back

@karuppiah7890 it would be great if you can share a reproduction.
Because to me, it seems like everything in the shared snippet is setup correctly.

Makes sense. I'll try to do that too with a demo setup 馃憤

Just a question, do you have a single instance of setupServer? or you have more test modules with different servers?

@marcosvega91 Ah yes. We have multiple instances 馃檲

I was thinking a bit about that too - how jest runs tests in parallel (across test files) with server running like that (same port and all). I need to dig a bit more and understand things 馃槄

EDIT: I forgot that it's still an interception and no actual server is running. 馃檲 So, I guess running multiple "servers" is not a problem (no port conflicting issues etc)

I was also thinking about merging all the related servers with just one server implementation - since almost all of them work in the same way with same data. It's just that I need to see how to do it. The current idea is to at least reuse the request handler (merge all request handler code, remove duplicates) and run server with that in the beforeAll setup

UPDATE: I upgraded the version, but I still saw the connection refused errors in the logs

I asked you that because we have an issue with this approach. https://github.com/mswjs/msw/issues/474

Monkey patched modules are shared between tests, so if one test close the server instance it could be possible that another running test will have the problem that you've described. Sorry for that 馃様

Thanks for the explanation @marcosvega91 ! And I think I understand why the current features are not supporting this, so need to be sorry :) I remember reading how it's good to have one implementation (the happy path) of the server and to run the server in the Jest Test setup, before any of the tests run and to have any specific changes needed for any tests (like bad request, error cases etc) in the particular tests using the programmatic API. I'll try to see if we can do that, and I'll also have an eye on #474 . Should I close this issue then? Assuming that this is just a duplicate or a side effect of what #474 describes?

Yes we can close this and use the other issue. Thanks and sorry for your trouble 馃槥

No worries!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dashed picture dashed  路  4Comments

abrudin picture abrudin  路  3Comments

hauptrolle picture hauptrolle  路  4Comments

slowselfip picture slowselfip  路  3Comments

mainfraame picture mainfraame  路  3Comments