Random Axios errors With Express, Jest and Supertest

Question

I'm having an issue with Supertest when testing Express endpoints whereby it will randomly fail, usually with a AxiosError: Request failed with status code 404 error that has no useful stack trace.

The error occurs on a random file each time. If I run that file's tests directly, they all pass fine, there is nothing actually wrong with any of the tests, they'll all pass when run directly.

The problem is when running the full suite of tests (about 280 tests across about 40 files). There will always be at least one, sometimes more of this same error:

  ● Test suite failed to run

    AxiosError: Request failed with status code 404

      at settle (node_modules/axios/lib/core/settle.js:19:12)
      at IncomingMessage.handleStreamEnd (node_modules/axios/lib/adapters/http.js:599:11)
      at Axios.request (node_modules/axios/lib/core/Axios.js:45:41)

The error does not seem to related to the tests in the file at all. Sometimes the test file that fails is a pure unit test that does not perform any sort of HTTP request, or even import anything with Axios, yet it will throw that same Axios error.

I found this issue with Supertest. I refactored all my tests to use this new startup and shutdown procedure, but it did nothing.

Another potentially useful bit of information is that the error always happens about half way to 3/4 through the full suite run. It never happens immediately, and always on a different test file.

How I can go about surfacing some more information to debug it? It's impossible to know where its happening as its failing tests that are not actually related to the error. I can't even show an example of a failing test because they all pass when run separately.

All of my tests follow this pattern:

const request = supertest(app);


describe("functionName", () => {
    it("should perform x", async () => {
      const res = await request.get("/v1/asset");
      const { result } = res.body;
      expect(res.status).toEqual(200);
      // etc etc
    });
});

An example of app:

import express from "express";

const app = express();
        app.get("/routes", (req, res) => {
            res.json({});
        });

export default app;

Running: Node 20.16, Yarn 4.4.0, Jest 29.7.0, Supertest 6.3.4

Answer 1

Answering my own question here in the event someone else comes across a similar issue as this was a tricky one to solve.

As mentioned above, the error was a generic exception thrown from Axios regarding some 404 response. It was occuring at seemlingly random times on random tests that didnt even perform Axios requests.

Stack trace was unhelpful, the error provided no useful information (there are hundreds of axios calls made in our app, which one is it?).

I was able to debug the source of the error by configuring a setup JS file within jest.config.js

    setupFilesAfterEnv: ["./tests/setupJest.ts"]

this file runs before all tests.

Within this file I configured an Axios interceptor to intercept Axios responses and error responses so that you can log out information about the request, the URL, method etc.

axios.interceptors.response.use(
  (response) => {
    // Any status code that lie within the range of 2xx cause this function to trigger
    // Do something with response data
    return response;
  },
  async (error) => {
    // Any status codes that falls outside the range of 2xx cause this function to trigger
    // Do something with response error
    console.log("AXIOS DEBUG", error.request.method, error.request.path, error.response.status, error.stack);
    return Promise.reject(error);
  }
);

Now when I run the test suite, in my console, above where this mystery 404 error was I can see the request path and method logged out, which in my case was a DELETE request to an external endpoint, basically a delete operation.

This narrowed down the potential culprit code significantly.

I reviewed all tests performing this operation and sure enough I found a single Axios delete request that was not awaited, so it was running and failing the request but at a time when another test had started.

Adding an await to this line, solved the issue, but I would of never have found this 1 single line of code in our 1 million+ line code base without this bit of information.

Hope that helps someone else from days of frustration.