fix(backend): force jest to run in-band to kill the socket-hang-up flake

Merged
LU
1mo ago
+9-5

Summary

Refs #2041, #2120.

Both issues track the same recurring flake: a different backend integration test fails each full-suite run (socket hang up, ECONNRESET, malformed HTTP framing), always passing 100% in isolation. #2041's own investigation root-caused it to ephemeral port/socket contention: integration tests each spin up a real supertest listening server, and running many of them concurrently across parallel Jest workers causes intermittent connection failures. #2120 (a twitch.test.ts instance of the same symptom) independently converged on the same conclusion.

The existing maxWorkers: '25%' mitigation (#1751, 2026-07-10) had the wrong rationale. Its comment blames "connection pool pressure" from concurrent database connections, but packages/backend/jest.config.cjs's moduleNameMapper fully mocks generated/prisma/client (tests/__mocks__/prismaClient.ts, zero shared state) - there is no real DB connection in this suite to contend over.

Set maxWorkers: 1 and replaced the stale comment with the correct root cause.

Test plan

  • 3 consecutive full npx jest runs at the previous '25%' setting: 1 failure (reproducing the documented flake), 2 clean
  • 3 consecutive full npx jest --maxWorkers=1 runs: 3/3 clean, 1410/1410 tests
  • Runtime cost: negligible (~87s at maxWorkers=1 vs ~82s at '25%' on this suite's current size)
  • tsc --noEmit clean across bot/backend/frontend/shared

Follow-up

Leaving #2041 and #2120 open post-merge rather than auto-closing - a probabilistic flake needs a run or two of real CI (not just local reproduction) before calling it fully resolved. Will close both once CI shows sustained green.

Summary by cubic

Fixes the backend integration flake from #2041 and #2120 by setting maxWorkers: 1 in packages/backend/jest.config.cjs, so a different test no longer fails each full-suite run with socket hang-ups and connection resets.

  • Parallel workers each spun up a real supertest listening server, causing ephemeral port/socket contention.
  • The previous '25%' setting blamed database connection pressure, but generated/prisma/client is fully mocked in this suite, so that rationale was wrong.
  • Runtime impact is negligible: ~87s at maxWorkers: 1 vs ~82s at '25%' on the current suite.