Repository navigation
Wait for a worktree's extract when the graph it would serve is from before an update - #140
Merged
Merged
Conversation
…efore an update After an update and a restart, the first lookup in a worktree was answered from the worktree's stored graph, extracted by the old graphify build against the old vlib, with a note that it was out of date. start_worktree now marks such a graph stale (stale_note), and the first lookup waits for the extract that is running, up to extract_wait, and answers from the graph it publishes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
Problem
After
bin/update-vlang-graph.vshand a restart of Claude, the first lookup in a worktree session was answered from the worktree's old graph, with this note:When the server starts in a worktree,
start_worktreeserves the graph an earlier server stored for the worktree, and starts extracting it again in the background. A lookup waited for that extract only when it found nothing (#135). After an update, the stored graph was extracted by the old graphify build against the old vlib, so the first lookups were answered from it, and the note said so. The next lookup, a few seconds later, had no note.Change
start_worktreemarks the worktreestalewhen the graph it serves from the start is out of date bystale_note: extracted by another graphify build, against another commit of a library, or from another commit of the worktree.App.answerfirst calls the newApp.wait_stale. While the worktree is stale and its extract runs, the lookup waits for the extract (wait_extract, up toextract_wait, 30 s) and answers from the graph it publishes. Once one lookup has waited, the flag is cleared and the others don't wait, even when the extract has not finished in time; they are answered as before, with the note.The first lookup after an update waits for the worktree's extract: about 1 s in a graphify worktree, up to about 20 s in a vlang worktree.
Tests
test_a_lookup_waits_for_the_extract_when_the_graph_served_is_from_before_an_update(cmd/mcp/main_test.v): a stale worktree whose extract publishes a graph with the function moved. The lookup is answered from the new graph, without the note. Without the call towait_staleit fails: the answer is from the old graph.test_a_graph_from_before_an_update_is_waited_for_once: an extract that does not finish in time is waited for once.v test .andv run bin/test-crlf.vshpass.🤖 Generated with Claude Code