[BUG] Deleted files leave stale vectors in Qdrant — not cleaned up until full re-index

[pcomte3]

Description

When a file (or directory) is deleted from the workspace, Roo Code does not remove the corresponding vectors from the Qdrant collection. The stale points persist indefinitely until a full re-index is triggered manually.

This means codebase_search can return context from files that no longer exist, which may mislead the AI assistant.

Steps to reproduce

1. Enable codebase indexing with a local Qdrant instance
2. Create a file (e.g., decisions/001-test.md) and wait for it to be indexed
3. Verify it appears in Qdrant via scroll/search
4. Delete the file (or its parent directory)
5. Edit and save another file to trigger the incremental file watcher
6. Query Qdrant — the deleted file's vectors are still present

Expected behavior

Deleted files should have their vectors removed from Qdrant promptly — either via the file system watcher (onDidDelete) or during the next incremental sync pass, not only on a full re-index.

Actual behavior

The _handleBatchDeletions logic in QdrantVectorStore.deletePointsByMultipleFilePaths exists but only runs during a full batch re-index. Incremental file change events (create/update) do not trigger cleanup of deleted files.

Feature request: collection alias at index creation

Additionally, Roo Code creates Qdrant collections with opaque hashed names (e.g., ws-fc1843e42d391b4f), derived from SHA-256(workspacePath).substring(0, 16). This makes it impossible for external tools to discover and query the collection without reverse-engineering the naming scheme.

It would be very useful if Roo Code created a Qdrant alias at index creation time using the workspace folder name (e.g., my-project → alias for ws-fc1843e42d391b4f). This would allow other AI assistants, scripts, and tools to query the same embeddings by a human-readable, stable name — maximizing the value of the index that Roo Code builds.

Qdrant already supports aliases natively via POST /collections/aliases.

Environment

• Roo Code: v3.52.0
• VS Code: macOS
• Qdrant: localhost:6333

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

Analysis

After reviewing the codebase, the situation is more nuanced than the initial report suggests:

Individual file deletions already work. The FileWatcher (src/services/code-index/processors/file-watcher.ts) registers an onDidDelete handler (line 119) that accumulates delete events and processes them through _handleBatchDeletions, which calls vectorStore.deletePointsByMultipleFilePaths. This correctly removes vectors for individually deleted files.

The actual gap is directory deletions. VSCode's FileSystemWatcher with extension-specific glob patterns (e.g. **/*.ts,**/*.js,...) does not fire onDidDelete for individual files when their parent directory is deleted. So deleting a directory leaves all its files' vectors orphaned in Qdrant.

During startup, deleted files ARE cleaned up. The DirectoryScanner.scanDirectory (scanner.ts lines 332-376) compares cached file paths against currently-existing files and removes orphaned vectors. So the stale data persists only until the next startup/re-index.

Proposed Changes

1. Handle directory deletions in the FileWatcher

In src/services/code-index/processors/file-watcher.ts, modify handleFileDeleted to detect whether the deleted URI was a directory. Since the path no longer exists on disk, we can check the cache manager for any cached file paths that start with the deleted path prefix, and queue those for deletion:

private async handleFileDeleted(uri: vscode.Uri): Promise<void> {
  const deletedPath = uri.fsPath;
  
  // Check if any cached files have this as a prefix (directory deletion)
  const allHashes = this.cacheManager.getAllHashes();
  const childPaths = Object.keys(allHashes).filter(
    cachedPath => cachedPath.startsWith(deletedPath + path.sep)
  );
  
  if (childPaths.length > 0) {
    // Directory was deleted - queue all child files for deletion
    for (const childPath of childPaths) {
      this.accumulatedEvents.set(childPath, { 
        uri: vscode.Uri.file(childPath), 
        type: "delete" 
      });
    }
  } else {
    // Single file deletion
    this.accumulatedEvents.set(deletedPath, { uri, type: "delete" });
  }
  
  this.scheduleBatchProcessing();
}

2. Add Qdrant collection alias on creation (Feature Request)

In src/services/code-index/vector-store/qdrant-client.ts, after creating a collection in initialize(), create a human-readable alias using the workspace folder name:

// After collection creation, create an alias using workspace folder name
const workspaceName = path.basename(this.workspacePath);
try {
  await this.client.updateCollectionAliases({
    actions: [
      { create_alias: { collection_name: this.collectionName, alias_name: workspaceName } }
    ]
  });
} catch (aliasError) {
  // Non-fatal - log warning but don't fail initialization
  console.warn(`[QdrantVectorStore] Could not create alias "${workspaceName}":`, aliasError);
}

3. Add tests

• Add a test to file-watcher.spec.ts verifying that when a directory deletion event fires, all child files from the cache are queued for vector deletion
• Add a test to qdrant-client.spec.ts verifying alias creation during initialization

This approach solves the core bug (stale vectors from directory deletions) while keeping the existing individual file deletion logic intact, and adds the requested alias feature.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[pcomte3]

@roomote i approve this plan.

[roomote-v0]

Thanks for the approval! I've seen your comment and will proceed with the implementation now. I'll open a draft PR shortly to share progress.

[roomote-v0]

Opened PR #12116 with my attempt at addressing this. It handles directory deletions by detecting child files in the cache and adds Qdrant collection aliases using the workspace folder name. All existing and new tests pass. Feedback welcome!