Skip to content

cache-refresh-lock-process: takeover-window race misclassifies completed-by-other even in a serial single-fork run #904

Description

@ozymandiashh

Observed on the #901 draft's runs, where the cache-lock files run in their OWN serial step (single forked worker), so this is not the parallel-pressure flake:

FAIL tests/cache-refresh-lock-process.test.ts
  > gives exactly one contender ownership of a stale zero-byte lock
AssertionError: a.completed-by-other,b.parsed: expected 'a.completed-by-other' to be 'a.timed-out'

Contender A observed the primary lock missing while the takeover guard was also missing and honestly classified the gap as completed-by-other; the test expected A to still be waiting at its deadline. On a slow shared runner the winner's unlink-guard/create-successor window is wide enough for A's poll to land inside it. Related by family to the verifyStillOwner/heartbeat guard race noted on #744.

Local datapoint (macOS/M-series, APFS): the sibling cache-refresh-lock.test.ts also fails several cases under full parallel runs and passes in isolation, count varying run to run, on unmodified main.

Consequence in #901: the serial cache-lock step runs with continue-on-error: true and points here, so the enforced signal stays trustworthy while this suite reports without gating. The step should lose the quarantine the moment the observation semantics around the takeover window are tightened (either the test's state-machine expectations widened to admit completed-by-other in that window, or the lock's missing+missing classification made stricter).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions