-
Notifications
You must be signed in to change notification settings - Fork 0
protocol,broker,node,cli,chaos: a leader seals its tail on demand — repair reaches its whole position (#306) #341
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
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
0d9cc01
protocol,broker,node,cli,chaos: a leader seals its tail on demand — r…
allamiro 462730d
broker,cli: the seal is fenced under the append path's own locks, and…
allamiro 0a84b1b
broker,cli: the seal's persistence window is stated, detected, and named
allamiro 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
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
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 retention is enabled and the committed former tail exceeds
max_total_bytes, an append arriving after this method returns but before the repair's separate listing request can delete the segment that was just sealed:flush_produce_groupcallsrun_retentionafter every successful append at lines 1673-1677, not only after an ordinary roll. The fresh evidence relative to the earlier comment is that this fix suppresses retention only insideseal_tail, so the cross-RPC window remains; the seal can report success while the following transfer cannot reachsealed_end. Keep the segment pinned until the transfer obtains its snapshot, or combine sealing with that snapshot.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.
Verified — you're right that the in-call suppression closes only half the window: run_retention fires after every successful append (confirmed at the flush_produce_group call site), so the cross-RPC slice remains. Where I land differently is on the consequence, and 0a84b1b encodes that reasoning rather than a pin: neither end of the window can produce a FALSE success — a shorter listing becomes a measured, reported gap (the #303 exit-1 contract), and a segment reclaimed mid-fetch is a clean resumable refusal, which is the same window every listed segment already lives in until its chunks land. A cross-RPC pin was considered and rejected with the reason now in the doc: the leader cannot know when a repairer is done, and a pin that outlives a crashed repairer is a retention bound that silently stopped being one. What the fix adds instead is DETECTION: the repair compares the seal's promised end with what the fenced listing actually held, and when retention won the race it names the cause to the operator instead of presenting a mysteriously shorter prefix. If a durable pin becomes worth its lifetime management, it deserves its own design slice against #290's retention semantics.