The perf-316 and perf-407 regression tests had two race-driven failure modes:
1. False-fail: setTimeout(80) before assert.ok(fs.existsSync(lockPath)) could
fire before Worker A finished writing the lock file under CI load. The
handoff noted this fired on origin/next's coverage job.
2. False-pass (latent): if Worker B raced past Worker A's release before
retrying, sabCount === 1 from the no-retry success path matched what
the PRE-FIX buggy code produced (one SAB for the single successful
open/write). The existing test had no witness for retry-path coverage,
violating test-rigor Contract 4 (exercise the path you claim to cover).
Fix (test-only):
- Replace setTimeout(80) with await-{pid}-message synchronization. Worker A
posts {pid} AFTER fs.writeFileSync/openSync returns (single-thread source
order within the worker), so by the time the parent receives it the lock
file exists on disk. The MessagePort buffers messages posted before the
parent attaches its listener, so there is no listener-race.
Ref: https://nodejs.org/api/worker_threads.html#event-message_1
- Add a 5000ms safety timeout on the lock-written signal so a hung Holder
worker surfaces as a specific error, not a generic test-timeout.
- Add a fs.openSync/fs.writeFileSync stub in Worker B that counts atomic-
create attempts (O_CREAT|O_EXCL for perf-316 / { flag: 'wx' } for perf-407).
Assert lockAttempts >= 2 to prove the SUT entered the retry loop. This
closes the Contract-4 hole: sabCount === 1 now discriminates pre-fix
(sabCount === lockAttempts) from post-fix (sabCount === 1, hoisted).
- Bump holdMs from 400ms to 1000ms to guarantee >=4 retries (perf-316,
200ms+jitter delay) or >=9 retries (perf-407, 100ms delay) on the
slowest CI worker. Test wall time grows ~600ms; well under the existing
8000ms timeout.
Closes#432
Co-authored-by: CI Rebase Check <ci@open-gsd.dev>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
acquireStateLock was allocating a fresh SharedArrayBuffer on every retry
iteration via Atomics.wait(new Int32Array(new SharedArrayBuffer(4)), ...).
The buffer is never mutated and never escapes, so hoisting it before the loop
is a provably-equivalent transformation — Atomics.wait always sees value 0
whether the buffer is fresh or reused.
Fixes#316
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
