You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(spec): stamp both sides of the browser-reachable freshness fixture from one anchor (#10626)
The self-test case "accepts a build newer than its sources" left the source
file at whatever mtime the OS wrote and stamped only the bundle, with
`new Date()`. The two clocks do not share a resolution and the mismatch runs
in the direction that fails a correct tree: `writeFileSync` stamps to the
nanosecond on ext4/tmpfs, `new Date()` carries whole milliseconds, so
`utimesSync(bundle, new Date())` can land up to 1 ms BEHIND a source written
microseconds earlier. `bundlesAreStale` then reads a bundle touched later in
wall-clock time as the older of the two and the case fails.
Nothing in the old code bought margin against that; the margin was whatever
the five syscalls in between happened to cost — 2.5-9.5 ms cold on this box,
under 1 ms when replayed hot, where the same fixture fails 378/500. One such
run reddened a merge-queue candidate and evicted a PR that cannot influence
this gate.
Both sides are now stamped from one integer-millisecond anchor and every case
states its own offset, the discipline dist-freshness.test.ts already applies
to this same library. Two cases join it: a bundle one millisecond older reads
stale (the reject side at its finest grain, which reddens if anyone ever
settles a flake here by widening the comparison into a tolerance window), and
an exact mtime tie reads fresh (the `>` boundary, previously unpinned). Every
freshness case now passes a detail so a failure prints the mtimes instead of
a bare cross.
No production behaviour changes: `bundlesAreStale` is untouched.
Claude-Session: https://claude.ai/code/session_01DdCnBGcHeufjrq7drTD3wt
Co-authored-by: Claude <noreply@anthropic.com>
0 commit comments