fix: recover from error state when Qdrant becomes available

[roomote]

This PR fixes the issue where code indexing gets stuck in an error state when Qdrant is unavailable at startup.

Problem

When VSCode starts without Qdrant running, the code indexing feature enters an error state. After starting Qdrant and clicking "Start Indexing", the error persists and requires a developer window reload.

Solution

• Added a recoverFromError() method to CodeIndexManager that clears the error state and resets internal service instances
• Updated the startIndexing handler in webviewMessageHandler.ts to check for error state and recover before attempting initialization
• Added comprehensive unit tests for the error recovery functionality

Testing

• All existing tests pass
• Added new test suite for recoverFromError method with 4 test cases
• Verified that the manager can recover from error state and be re-initialized

Fixes #6660

---

Important

Adds error recovery to CodeIndexManager for Qdrant unavailability, ensuring re-initialization without reload.

• Behavior:
  • Adds recoverFromError() to CodeIndexManager to clear error state and reset services.
  • Updates startIndexing in webviewMessageHandler.ts to check and recover from error state before initialization.
• Testing:
  • Adds unit tests for recoverFromError() in manager.spec.ts with 4 test cases.
  • Verifies manager recovery and re-initialization.
• Misc:
  • Minor changes in webviewMessageHandler.ts to handle re-initialization after error recovery.

^{This description was created by for ff8867b. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Reviewing my own code is like debugging in a mirror - everything looks backwards but the bugs are still mine.

[roomote]

Could we enhance the JSDoc to mention that this method clears all service instances and requires re-initialization? This would help future developers understand the full impact of calling this method.

[roomote]

Nice comprehensive test coverage! Consider adding one more edge case test: what happens when recoverFromError() is called on a manager that's not in error state? This would ensure the method is idempotent and safe to call in any state.

[daniel-lxs]

@roomote-agent address the points from the review, push to this PR

[roomote]

I see the review comments and will address the following points:

1. Add protection against race conditions for multiple rapid clicks on "Start Indexing"
2. Add error handling for setSystemState in the recovery method
3. Enhance JSDoc documentation for the recoverFromError method
4. Add test case for calling recoverFromError when not in error state

Working on these changes now.

[roomote]

✅ Review comments addressed

I've successfully addressed all the review points:

1. Race condition protection (webviewMessageHandler.ts:2206)

• Added a module-level flag isRecoveringFromIndexingError to prevent concurrent recovery attempts
• Multiple rapid clicks on "Start Indexing" are now safely handled with early return and logging

2. Error handling for setSystemState (manager.ts:188)

• Wrapped setSystemState call in try-catch block
• Recovery continues even if state update fails, ensuring service instances are always cleared
• Errors are logged to console for debugging

3. Enhanced JSDoc documentation (manager.ts:183)

• Added comprehensive documentation explaining the method's behavior
• Documented that it clears all service instances for complete re-initialization
• Added @remarks section noting the method is idempotent and safe to call in any state

4. Test coverage for non-error state

• Added test case verifying recoverFromError is safe to call when not in error state
• Added test case ensuring recovery continues even if setSystemState throws an error
• All tests pass successfully

Changes summary:

• src/core/webview/webviewMessageHandler.ts: Added race condition protection
• src/services/code-index/manager.ts: Enhanced error handling and documentation
• src/services/code-index/tests/manager.spec.ts: Added comprehensive test cases

All tests pass locally and the code has been linted. The changes ensure robust error recovery for the code indexing feature.

[daniel-lxs]

LGTM