Skip to content

Wait for a worktree's extract when the graph it would serve is from before an update - #140

Merged
quaesitor-scientiam merged 1 commit into
masterfrom
claude/wait-stale-worktree-graph
Oct 28, 2026
Merged

quaesitor-scientiam merged 1 commit into
masterfrom
claude/wait-stale-worktree-graph

Conversation

@quaesitor-scientiam

Copy link
Copy Markdown
Owner

Problem

After bin/update-vlang-graph.vsh and a restart of Claude, the first lookup in a worktree session was answered from the worktree's old graph, with this note:

the worktree has changed since its graph was extracted; it is being extracted again. The project: this graph may be out of date: its library (vlib) was read from … at f0bbdd9d1d, which is at 6dd8bb85fc now; it was extracted by a different graphify build than …

When the server starts in a worktree, start_worktree serves 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_worktree marks the worktree stale when the graph it serves from the start is out of date by stale_note: extracted by another graphify build, against another commit of a library, or from another commit of the worktree.
  • App.answer first calls the new App.wait_stale. While the worktree is stale and its extract runs, the lookup waits for the extract (wait_extract, up to extract_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.
  • A graph that is up to date is served at once, as before, and an edit in the worktree is still re-extracted in the background without a wait.

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 to wait_stale it 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 . and v run bin/test-crlf.vsh pass.

🤖 Generated with Claude Code

…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>
@quaesitor-scientiam
quaesitor-scientiam merged commit 69b1e81 into master Oct 28, 2026
14 checks passed
@quaesitor-scientiam
quaesitor-scientiam deleted the claude/wait-stale-worktree-graph branch October 28, 2026 20:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant