search

chaijs / chai-http

HTTP Response assertions for the Chai Assertion Library.
http://chaijs.com/plugins/chai-http
634 stars 113 forks source link

arbitrary 404 errors #270

Open natanavra opened 4 years ago

natanavra commented 4 years ago

TL;DR if you chai-request is inconsistent and sometimes responds with 404 add --retries 1 to your mocha.opts it seems there a race-condition of some sort where the http server is listening but not yet accepting connections.

chai.request(app) randomly responds with 404 even after successful previous tests. DEBUG output:

nock.common options.host: 127.0.0.1 +9ms
nock.common options.hostname in the end: "127.0.0.1" +0ms
nock.common options.host in the end: "127.0.0.1:64399" +0ms
nock.intercept interceptors for "127.0.0.1:64399" +9ms
nock.intercept filtering interceptors for basepath http://127.0.0.1:64399 +0ms
nock.common options.host: 127.0.0.1:64399 +0ms
nock.common options.hostname in the end: "127.0.0.1" +0ms
nock.common options.host in the end: "127.0.0.1:64399" +0ms
nock.intercept Net connect  enabled for 127.0.0.1:64399 +0ms
superagent post http://127.0.0.1:64399/pub/sites/wf/state +3ms
superagent post http://127.0.0.1:64399/pub/sites/wf/state -> 404 +1ms

When this doesn't happen - there are usually express DEBUG logs between the two superagent logs, e.g.

superagent options http://127.0.0.1:64357/abcda -> 200 +4ms
...express:router <anonymous>  : /abcda +0ms
superagent options http://127.0.0.1:64357/abcda +130ms

A couple of ideas come to mind:

EDIT: I thought this might be related to server.listen since NodeJS documentation states it's asynchronous, so I've added event listeners.

listen always happens before superagent DEBUG logs, but when the 404 happens none of the other events are being called, a connection is not being opened.

I've also updated superagent to the latest version ^5.0.0 but still no luck.

I thought about further changing the chai-http/request to be fully async and wait for httpServer.listen callback, but that breaks the superagent method chaining

Right now my workaround is adding --retries 1 to mocha.opts