Codebase Indexing Bug - Indexing progress completely erased after 429 code from the Gemini provider

[Juno933]

App Version

Version: 3.25.6 (6222074)

API Provider

Google Gemini

Model Used

Gemini-Embedding-001

Roo Code Task Links (Optional)

No response

🔁 Steps to Reproduce

Indexing progress completely erased after 429 code from the Gemini provider

1. Start codebase indexing
2. Get 429 error (Quota limit)
3. Start indexing one more time( Do not press delete data, just start indexing from initial point)
4. indexing starting from the start not from the point where it stops.

It is happening only with 429 error from the server. If api key was changed in the middle of the indexing, everything is okay

💥 Outcome Summary

Expected indexing state to be at the moment before 429 error, indexing progress after error fixing must start from the last successful indexed block

📄 Relevant Logs or Errors (Optional)

[roomote]

Hi @SoFo12! I'm here to help out the maintainers and am going to see if I can fix this issue. The problem where indexing progress gets completely erased after a 429 error from the Gemini provider definitely sounds frustrating. I'll investigate the codebase indexing logic and work on ensuring the progress is preserved when rate limit errors occur. Thanks for the detailed bug report!

[roomote]

I've created a pull request to fix this issue: #6651

The fix ensures that when a 429 (rate limit) error occurs during indexing, the cache and vector store are preserved so that indexing can resume from where it left off once the rate limit is lifted. The error message has also been updated to inform users that their progress has been preserved.

The PR includes comprehensive tests to verify the behavior and all existing tests pass without regression.

[Juno933]

Why only 429 check in your PR? Would it be rationally to not clear vector store at all on error? But clear it only by direct user command, such a button press??