Intermitent failure in draws an SVG for synthetic data example 1 test

[adamnovak]

Since #147, one of our tests (draws an SVG for synthetic data example 1) has been failing intermittently. The test actually runs through, but the harness says it failed because of:

    ReferenceError: setImmediate is not defined

      at next (node_modules/express/lib/router/index.js:202:7)
      at Layer.handle [as handle_request] (node_modules/express/lib/router/layer.js:97:5)
      at trim_prefix (node_modules/express/lib/router/index.js:323:13)
      at node_modules/express/lib/router/index.js:284:7
      at Function.process_params (node_modules/express/lib/router/index.js:341:12)
      at next (node_modules/express/lib/router/index.js:275:10)
      at SendStream.error (node_modules/serve-static/index.js:121:7)
      at SendStream.error (node_modules/send/index.js:270:17)
      at SendStream.onStatError (node_modules/send/index.js:421:12)
      at next (node_modules/send/index.js:735:16)
      at onstat (node_modules/send/index.js:724:14)

To reproduce the error, you need to run three test cases in the same run:

npm run test -- --watchAll=false --maxConcurrency 1 --maxWorkers 1 --testNamePattern "(eventually stops rendering as loading|the regions from the BED files are loaded|draws an SVG for synthetic data example 1)" src/end-to-end.test.js

Running the same code all in one test case doesn't produce the failure. If you use -i instead of --maxWorkers 1, it still fails, but if you add --detectOpenHandles to the above command, it starts passing.

I think this is related to jestjs/jest#11222. Our tests are run under react-scripts's idea of what a JS environment should be, so Jest is trying to mimic a browser, I think. They recently (well a year ago, but recently for us) dropped setImmediate from their browser-esque sandbox, because only one browser has it.

Under some particular weird conditions, the backend code tries to call setImmediate, but since we're in Jest's sendbox, it can't, and it fails. This is all happening in the server code that's running concurrent with the actual test, so the failure is there and not really in the test code, but still gets counted against the test.

Either we need to polyfill setImmediate in the server code when it's not there, or we need to figure out a better way of getting a React test to have a (mock?) server available, by maybe mocking all the API requests we expect it to make and providing it with canned responses.

@olivewong Do you have a Right Way of testing React components that want to make web requests that we could apply here?

[olivewong]

I'll look into ways we could mock API requests and reproducing this since I'm currently getting a timeout running that. Alternatively, could downgrading Jest to before jestjs/jest#11222 or another one of these be an alternate solution?