fix: make stale lock ticket reaping single-winner on Windows - #444
Merged
Conversation
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Paperclip <noreply@paperclip.ing>
review) AcquireLockOptions is re-exported through core/index.ts, so the fsOps test seam was emitted into dist/core/status.d.ts and offered to every consumer of the published types. stripInternal drops members marked @internal from declarations; runtime code is unchanged. fsOps is the only @internal in core/, mcp-server/ or extensions/.
TheAmericanMaker
marked this pull request as ready for review
September 26, 2026 07:03
TheAmericanMaker
deleted the
paperclip/HUGA-3-fix-435-stale-lock-ticket-reaping-on-windows-removeifpresent-only-treats-enoent-as-a-lost-race
branch
September 26, 2026 07:03
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #435
What changed
wxbefore renaming a stale ticket to a unique tombstone. The Windows runner showed two successful renames of the same source path; only the marker creator can now reportbrokeStale.EPERM,EBUSY, orEACCESon claim rename as a retry while the source exists, or as a lost race if it is gone. Other errors still surface, and the waiter's heartbeat and ticket are cleaned up on exit.ENOENTfrom ticketstatas evidence that the owner claim disappeared. Sweep old tombstones and claim markers, and remove a marker once its source is gone.Regression coverage
Windows claim contention retries while the stale ticket still exists: injectedEPERM,EBUSY, andEACCES, then succeeded on retry.Windows claim errors after another waiter removed the ticket do not report a break: injected the same codes after removing the source.only one waiter reports a break when Windows exposes the source after rename succeeds: models the behavior observed in Windows CI, ensuring a second waiter does not report a break.a claim error removes this waiter's ticket before rejecting: injectedEIOand verified cleanup.ENOENTstat tests remain.Before the follow-up fix,
Windows claim contention retries while the stale ticket still existsfailed againstf0e709e:not ok 1,error: 'ticket held open by another waiter',code: 'EPERM'. Windows CI ond2387b0recorded two successful renames of the exact same planted ticket path, which prompted the exclusive marker.Verification
npm run build: passed.node --experimental-strip-types --disable-warning=ExperimentalWarning --test tests/state-store.test.mjs: 26 passed, 0 failed.npm test: 1,295 passed, 0 failed.git diff --check: passed.Windows-only filesystem behavior has not been run locally on this Linux machine;
test-windowsin CI must verify it alongsidetest (22)andtest (24).