fix(mcp): cancel the in-flight index before a force re-index instead of orphaning it - #429
Open
EricSeastrand wants to merge 1 commit into
Open
Conversation
…of orphaning it `handleIndexCodebase` with `force: true` on a codebase that is currently being indexed calls `removeCodebaseCompletely()` and carries on. That clears the snapshot entry but does not stop the background task: it keeps embedding and writing chunks into the collection the new run is rebuilding, and its completion handler later writes stats for a run nobody is watching. This is the orphaned-writer bug that zilliztech#199 fixed for `clear_index`, which does it correctly — abort the `AbortController`, await the task's promise, then touch the collection. The `indexingTasks` map added there already holds everything needed; the force path just never learned to use it. Force now cancels and awaits wind-down before clearing the snapshot entry and starting the new index, mirroring `handleClearIndex`. Behaviour is otherwise unchanged: force still proceeds, and a non-force call still returns "already being indexed" without cancelling anything. `handlers.force-during-indexing.test.ts` registers a fake in-flight task and asserts the signal is aborted, wind-down completes before the handler moves on, and the task is removed from `indexingTasks`. It fails on master (the signal is never aborted).
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
handleIndexCodebasewithforce: true, on a codebase that is currently being indexed:https://github.com/zilliztech/claude-context/blob/6fc318b/packages/mcp/src/handlers.ts#L377-L392
Removing the snapshot entry does not stop the background task. The old run keeps embedding and writing chunks into the collection the new run is rebuilding, and its completion handler later writes stats for a run nobody is tracking. Two writers, one collection, no ordering.
This is exactly the orphaned-writer bug that #199 fixed for
clear_index— andhandleClearIndexalready does it right:The
indexingTasksmap is already populated for every background index. The force path just never used it.Change
The force branch now cancels and awaits wind-down before clearing the snapshot entry, mirroring
handleClearIndex. No new machinery, no new state.Unchanged: force still proceeds to re-index afterwards, and a non-force call on an in-flight index still returns "already being indexed in the background" without cancelling anything.
Test
packages/mcp/src/handlers.force-during-indexing.test.tsregisters a fake in-flight task whose promise only settles after its abort signal fires, then calls the handler withforce: true. Asserts:indexingTasks;It fails on
master(controller.signal.aborted === false) and passes with this change.pnpm --filter @zilliz/claude-context-mcp test→ 8/8;tsc --noEmitclean.