ci: test_gap_fs_fd_2749 is flaky on CI (passes 5/5 locally) — the last untriaged gap failure, randomly reds the required conformance gate

[proggeramlug]

Summary

test_gap_fs_fd_2749 fails intermittently on CI and passes consistently locally. It is the only remaining untriaged gap failure, so every time it flakes it turns conformance-smoke — a required check — red on an unrelated PR.

Evidence

• Locally, on current main (release build, quiet box): 5/5 runs PASS, byte-identical to node --experimental-strip-types.
• On CI: red on PR fix(windows): unbreak Windows-host cross-links and the Android default output (#5740, #6333) #6389, which touches only Windows path/response-file/link code (link/mod.rs, platform_cmd.rs, output_path.rs) — it cannot affect an fs test. Same story earlier on fix(gc): prune DATA_VIEW_REGISTRY and SHARED_ARRAY_BUFFER_REGISTRY on buffer death (#6337) #6341 (a GC registry-pruning PR) and on shard 5 of ci: run the integration suites a PR's diff names (#5960) #6338 (a CI-only PR that changes no Rust at all).

A PR that touches no Rust reddening an fs test is definitionally a flake, not a regression.

Why this matters more than one test

test-parity/known_failures.json has 33 triaged entries, and after #6363 and #6364 landed, this is the last untriaged one. So the no-new-untriaged gate is otherwise clean — meaning this single test is now the sole source of random red on the required conformance gate. That is exactly the condition that trains people to ignore a red gate, which is how the regressions this gate exists to catch (#5763, the 851-case test262 regression) got in.

Please do NOT just add it to known_failures.json

That would hide it. Two possibilities and they need different fixes:

1. A harness/environment flake — fd exhaustion, a temp-path collision, or timing sensitivity, made worse by 8 conformance shards running concurrently on one runner. Fix the test's isolation (unique temp dirs, explicit fd close, no reliance on wall-clock).
2. A genuine intermittent bug in Perry's fd handling that only surfaces under load. That would be a real defect and is worth much more than a skip-list line.

Reproducing it likely needs load: run the gap suite (or just this test) with concurrency on a busy machine, rather than standalone.

[proggeramlug]

This was fixed by #6400 / commit e2e79f780 (and later carried into current main). The root cause was the Node oracle itself: the three callback-form fd mutations complete in nondeterministic libuv threadpool order. The fixture now buffers all three results and prints them in a fixed order while preserving every err.code / err.syscall assertion.

The fix commit recorded 60 stable Node runs and 40 stable Perry runs with byte-identical output. I also re-ran the authoritative filtered release harness on current code today:

./run_parity_tests.sh --filter test_gap_fs_fd_2749
PASS  test_gap_fs_fd_2749
Parity Pass: 1
Parity Fail: 0
Compile Fail: 0
Crashed: 0

Closing this orphaned tracker as completed.