fix(shard): drive metadata repair and the commit walk from the tick - #4008
Open
numinnex wants to merge 4 commits into
Open
fix(shard): drive metadata repair and the commit walk from the tick#4008numinnex wants to merge 4 commits into
numinnex wants to merge 4 commits into
Conversation
Contributor
Author
|
Merge after #4006 |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4008 +/- ##
============================================
- Coverage 84.91% 83.94% -0.98%
Complexity 1405 1405
============================================
Files 1224 1225 +1
Lines 179327 180931 +1604
Branches 145615 147219 +1604
============================================
- Hits 152273 151879 -394
- Misses 23026 25083 +2057
+ Partials 4028 3969 -59
🚀 New features to boost your workflow:
|
numinnex
force-pushed
the
metadata_repair_and_commit_from_tick
branch
from
August 31, 2026 14:36
1a9fbc3 to
d5c8ba1
Compare
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
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.
A metadata backup that fell behind had no way back on its own, the same starvation the partition plane just had. A follower advances commit_max from every prepare header in replicate_preflight, before the gap check drops the prepare, so the commit heartbeat lands as Accepted rather than Advanced and the arming site inside that branch never fires. Under sustained metadata traffic the gap wedged until an unrelated view change. The same starvation left a backup holding resident committed ops that nothing re-drove, since the follower walk runs at the tail of an accepted prepare and the gap check returns before it.
▎
▎ The metadata tick now evaluates the same two level-triggered checks the partition driver uses, off one probe. A hole below commit_max arms the existing repair against the primary, debounced on the repair retry interval. Resident committed ops re-drive the walk, follower only, because a backup's walk ships no wire replies while a stranded primary is resume_stranded_commits' job. A gap below the serving peer's retention floor needs no special handling: the serve path answers RangeEvicted and the existing conversion arms a state transfer.