-
Notifications
You must be signed in to change notification settings - Fork 0
fix(native-playground): adopt a hard-linked catalog winner while its staging link is still present #377
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
fix(native-playground): adopt a hard-linked catalog winner while its staging link is still present #377
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| --- | ||
| "agent-bundle": patch | ||
| --- | ||
|
|
||
| Native Playground catalog readers no longer reject a sidecar that a concurrent publisher has just hard-linked into place but not yet released its staging file for. Hard-link publication legitimately leaves the sidecar doubly linked until the winner unlinks its `.stage-` file; a loser (or any reader) arriving inside that window previously failed with `Native Playground catalog snapshot is invalid.` instead of adopting the winner. The extra link is now accounted for by identity — exactly one same-epoch staging sibling shares the sidecar's dev/ino, or the still-open handle reports a single link once the staging file is gone — and any other extra hard link stays rejected as aliasing. |
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When the winning publisher fails its directory fsync or staging-file cleanup after
link(), its staging link is still present while#persistSnapshotproceeds to roll the sidecar back. A concurrentcatalog()orpublishCatalogSnapshot()now returns successfully here and caches an accepted snapshot, after which the owner can remove the sidecar during rollback; the successful reader therefore exposes an epoch whose supposedly persisted catalog no longer exists, and a later restart may rediscover different eval configuration. Treat the matching staging link as an in-progress publication and only accept the sidecar after it becomes singly linked and stable.Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed on main in #408 (a00273b):
#readSidecarnow treats a doubly linked sidecar with a matching.<epoch>.stage-*sibling as a publication in progress. It polls the open handle until it is singly linked and the sidecar path still names that inode (accept), or the path was withdrawn/replaced (return to discovery, never cache), and rejects a staging link that has not settled within 5 s. Tests: the linked-winner test now asserts the reader stays pending until the staging link is released; a new test stalls the winner's staging cleanup, fails it, and verifies the reader never adopts the rolled-back inode and republishes its own singly linked sidecar.