Flaky test: CORS only forwards content-type from upstream responses

[kmcginnes]

graph-explorer-proxy-server > createApp > CORS > only forwards content-type from upstream responses (packages/graph-explorer-proxy-server/src/app.test.ts:187) fails intermittently. It is not related to any current change — it surfaced incidentally during unrelated work.

Reproduction rate

Genuinely intermittent and not reproducible on demand:

how	result
pnpm test app.test -- -t "only forwards content-type", 6 runs	1 failure
same, 25 further runs	0 failures
whole graph-explorer-proxy-server package, 8 runs	0 failures
full workspace pnpm test	1 failure observed once, across many green runs

Both observed failures came from runs with other work in flight, so contention or timing is the likeliest ingredient. Passes consistently when the file is run on its own.

Ruled out

Mock queue leakage. The obvious suspect — mockFetchOnce uses mockResolvedValueOnce, so a value queued by one test and not consumed would be picked up by the next. But app.test.ts:71-73 calls mockFetch.mockReset() in beforeEach, which clears the queue. So a stale one-shot response is not the cause for sequential runs within the file.

What the test does

mockFetchOnce(JSON.stringify({ results: [] }), 200, {
  "content-type": "application/json",
  "access-control-allow-origin": "https://upstream.example.com",
  "transfer-encoding": "chunked",
  server: "Neptune/1.0",
  "x-request-id": "abc-123",
});

const response = await request(app).post("/sparql").set(dbHeaders()).send({ query: "SELECT 1" });

expect(response.headers["content-type"]).toContain("application/json");
expect(response.headers["access-control-allow-origin"]).toBeUndefined();
expect(response.headers["server"]).toBeUndefined();
expect(response.headers["x-request-id"]).toBeUndefined();

I was unable to capture the failing assertion — every attempt to reproduce with output captured came back green. So it is unknown which of the four expectations fails, which is the first thing to establish.

Suggested approach

1. Get the assertion. Run the full workspace suite in a loop with output retained, or temporarily raise reporter verbosity for this file in CI, until it fails once.
2. Suspect the interaction between the mocked upstream transfer-encoding: chunked header and supertest/express, which can change how the response is framed and therefore how headers are surfaced — a plausible source of timing sensitivity, given the test only fails under load.
3. Check whether the test depends on a shared port or server instance with a sibling test in the same file (createTestApp() is called per test, so verify nothing outside it is shared).

Low priority — a rare CI flake, not a product defect. Filing so a red build on this test is recognised rather than re-investigated.

---

Important

Internal only — this issue is maintained by the core team and is not accepting external contributions.