[BUG] Start Indexing runs two rebuilds at once and logs an unhandled 'CodeIndexManager not initialized' error #59

Type

Bug

Problem / Value

Clicking Start Indexing while the index is in Standby with its services still alive (the state that #57 leaves behind) starts two service rebuilds at the same time. The first rebuild is superseded and then throws CodeIndexManager not initialized. Call initialize() first. as an unhandled promise rejection. Indexing still restarts because the second rebuild wins, but the error looks like the cause of the outage and sends investigation the wrong way. The click also does redundant work (two embedder validations), and other timings could start a third rebuild.

Context

Observed 2026-11-02 19:02:05 PST in %APPDATA%\Code\logs\<session>\window1\exthost\exthost.log. It is not in the Roo-Code output channel, because the handler never awaited the promise and its catch never saw the error:

2026-11-02 19:02:05.572 [error] Error: CodeIndexManager not initialized. Call initialize() first.
	at t.assertInitialized (%USERPROFILE%\.vscode\extensions\rooveterinaryinc.roo-cline-3.53.7\dist\extension.js:2608:35242)
	at t.startIndexing (%USERPROFILE%\.vscode\extensions\rooveterinaryinc.roo-cline-3.53.7\dist\extension.js:2608:37134)
	at process.processTicksAndRejections (node:internal/process/task_queues:104:5)

Sequence, fork main @ 9c78783:

1. webviewMessageHandler.ts#L2422: await manager.initialize(). Services are alive and not stopped (manager.ts#L225), so nothing is rebuilt.
2. L2424: the state is Standby → L2426: manager.startIndexing() is called without await or .catch.
3. manager.ts#L250-L262: state Standby → await this._recreateServices() (attempt N). Before its first await, L384-L392 bumps the attempt counter, calls stopWatcher() (which sets servicesStopped = true, L290) and clears _orchestrator.
4. Back in the handler, L2428-L2429: !manager.isInitialized is now true → await manager.initialize() → servicesStopped is true → _recreateServices() runs again (attempt N+1).
5. Attempt N is now stale and returns early (L427-L429 or L441) without creating an orchestrator → L271 this.assertInitialized() throws → unhandled rejection.
6. Attempt N+1 finishes and initialize() starts indexing (L232-L237). The second startIndexing() at L2430-L2431 is skipped only because the state is now Indexing.

The same unawaited call appears at L2469 (toggleWorkspaceIndexing) and L2503 (setAutoEnableDefault), so any rejection there is unhandled too. The doc comment at manager.ts#L247 ("should NEVER be awaited") encourages calls without .catch.

• verified: the stack frames match assertInitialized ← startIndexing resumed after an await. Local uncommitted changes to webviewMessageHandler.ts don't touch these handlers.

Reproduction

1. Get the index into Standby with live services (for example, with the reproduction in [BUG] One failed file keeps the code index in Standby and blocks codebase_search until a manual restart #57).
2. Click Start Indexing.
3. Observe the unhandled CodeIndexManager not initialized error in exthost.log and two _recreateServices() attempts (two embedder validations).

Unit-level: with services alive and state Standby, dispatch startIndexing → assert exactly one rebuild and no unhandled rejection.

Acceptance criteria

• One Start Indexing click triggers exactly one rebuild-and-start sequence, from Standby and from Error.
• No unhandled rejections from Start Indexing, Toggle Workspace Indexing, or the auto-enable default; failures are caught, logged to the Roo-Code output channel, and reflected in the status.
• The startIndexing() contract is clarified (for example: safe to await until services are started while the scan continues in the background, or every caller must attach .catch), and the doc comment is updated to match.
• Tests cover Start Indexing from Standby with live services, from Error, and a double click.

Constraints/Preferences

Keep PR #34's attempt fencing (currentAttempt / isCurrentAttempt).

Related: PR #34, #57, #60