chai-http icon indicating copy to clipboard operation
chai-http copied to clipboard

arbitrary 404 errors

Open natanavra opened this issue 4 years ago • 0 comments

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:

  • Possibly due to a bug in an old superagent dependancy
  • nock is causing a quirk in the HTTP req/res cycle

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

  • listening
  • connection
  • request

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

natanavra avatar Apr 08 '20 10:04 natanavra