fix(code-index): never join clone backfill from a freshness read - #1770
Merged
Merged
Conversation
A live blocked status request was waiting in clone_index_status on the clone successor slot mutex. Backfill holds that lock for a whole bounded batch, so status, dashboard freshness, unmounted-files, and doctor reads could stall for 30-120 seconds behind production work. Read the slot with try_lock instead; a busy slot returns the typed unavailable clone-status snapshot immediately. The dashboard-level regression holds the slot and requires that result within 100 ms.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
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.
Reproduction
On the local current-master daemon, both
tracedecay tool statusandtracedecay statusblocked past 90/30 seconds while clone backfill ran. Attaching gdb during the blocked request gave the exact stack:text_projection_needs_workalready states and implements the invariant: a read probe must not queue behind an advance because backfill holds the slot for its whole bounded slice; contention itself means work is in progress.clone_successor_progress, called byclone_index_status, still used blockinglock_slot().Checked #1577 first: it changes clone codec/decode, not
clone_index_status,clone_successor_progress, or this lock.Fix
clone_successor_progressusestry_lockand returns an explicitBusyread state.clone_index_statusmaps that to the existing typed status:No guessed progress counters and no new wire state. The artifact/census read happens only after the slot snapshot succeeds.
Behavior test
dashboard_freshness_does_not_join_a_clone_backfill_slicedrives a mounted registry, obtains ready text owners, holds the backfill slot, then calls the public dashboard freshness surface. It must return the typed busy clone status within 100 ms. The old code deadlocks on the held slot and fails the timeout.Focused clone-status tests: 2/2. All dashboard-freshness runtime tests: 3/3. rustfmt and IDE lints clean.