fix(mcp): stop a replaced code engine's autosync loop - #25
Merged
Merged
Conversation
Each index-version bump rebuilt the cached engine but never stopped the old one; its autosync thread kept it alive, so every bump added a loop that polled the tree and spawned its own reindex. On a large repo the index-write lock stayed held and code_search answered 'index is being rebuilt'.
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
code_searchanswered "code index … is being rebuilt (index-write lock is held)" for about two thirds of calls in symphony-alpha. Part of the cause is here.Since
8ea1eb15, the MCP daemon rebuilds its cachedCodeContextEnginewhenever the index version moves. It never stopped the engine it replaced. Each engine runs an autosync thread, and that thread keeps the engine alive, so every index bump left one more loop behind. Each leaked loop polled the tree and spawned its ownlc code indexfor every change, and those reindexes bumped the version again.Measured on the live symphony-alpha daemon:
Reproduced in isolation: 5 version bumps left 6 live autosync loops, and one file edit started 6 reindex subprocesses.
Fix
VersionedEngineCachegains anon_evicthook. It is called for every value the cache lets go of (superseded, discarded or cleared), outside the cache lock._retire_code_engine, which calls the new publicCodeContextEngine.stop_autosync().After the fix, the same reproduction leaves 1 loop and 1 reindex per change.
Tests
_code_context_enginethrough a version bump and asserts the replaced engine was stopped.tests/infra/code_intelbecausetests/gateway/conftest.pyforces autosync off.All of them fail without the fix. They also catch two narrower breakages: the daemon not wiring the hook, and the cache not calling it.
The gateway and code-intel suites give the same 8 failures on this branch as on
main(daemon socket races, installer, read budget, savings ledger), all present before this change.Related
One of three independent fixes for code search failing on symphony-alpha:
fix/code-engine-autosync-leak,fix/incremental-reindex-batched-deletes,fix/search-reads-during-reindex. Each is based onmain, and all three merge cleanly in any order (checked withgit merge-tree, and their new tests pass together on an octopus merge).