Dynamically adjust the retry timer for Google Gemini based on the delay its API returns

[dabockster]

What specific problem does this solve?

When using the Google Gemini provider (especially the free version), Google's systems will rate limit the requests coming from Roo Code. However, in the response it sends, Gemini's API does also send a retry time delay in seconds (eg "retryDelay": "40s"). I think Roo Code could use this pragmatically to better integrate with the Gemini system (that time delay plus a couple seconds for safety).

Additional context (optional)

No response

Roo Code Task Links (Optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear impact and context

Interested in implementing this?

• Yes, I'd like to help implement this feature

Implementation requirements

• I understand this needs approval before implementation begins

How should this be solved? (REQUIRED if contributing, optional otherwise)

Roo Code should be able to dynamically set its own rate limit for Google models based on the rate delay information Google's API returns back. It should also alert the user if the API returns a message implying a daily quota has been exceeded.

How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)

The user shouldn't see messages like this unless the quota is genuinely exhausted and not rate limited:

Gemini generate context stream error: got status: 429 Too Many Requests. {"error":{"message":"{\n "error": {\n "code": 429,\n "message": "You exceeded your current quota, please check your plan and billing details. For more information on this error, head to: [https://ai.google.dev/gemini-api/docs/rate-limits.\",\n](https://ai.google.dev/gemini-api/docs/rate-limits.%5C%22,%5Cn) "status": "RESOURCE_EXHAUSTED"

Roo Code would be that much more automated in this way.

Technical considerations (REQUIRED if contributing, optional otherwise)

Could break if Google changes their API

Trade-offs and risks (REQUIRED if contributing, optional otherwise)

I don't see any tradeoffs at this time.

[roomote]

I'm here to help out the maintainers and am going to see if I can fix this issue! I'll implement dynamic retry timing for Google Gemini based on the retryDelay value returned by their API. This should help avoid unnecessary rate limit errors and improve the user experience when using Gemini models.

[hannesrudolph]

I don't see the retryDelay or anything of the sort in your response from Gemini.

[roomote]

I've successfully implemented the dynamic retry timing for Google Gemini API! 🎉

The implementation is now available in PR #6682: #6682

What was done:

• Enhanced the GeminiHandler error handling to preserve the original error structure including retry delay information
• Added logic to distinguish between rate limits (which will be automatically retried) and quota exhaustion (which requires user action)
• Added new localized error messages that provide clearer feedback to users
• Added comprehensive test coverage for all new scenarios

The existing retry logic in Task.ts already extracts and uses the retryDelay from Gemini's error responses, so this change ensures that information is properly preserved and passed through.

CI checks are currently running on the PR. Once they pass, the changes will be ready for review and merge.

[dabockster]

I don't see the retryDelay or anything of the sort in your response from Gemini.

@hannesrudolph I didn't include the whole response since it looked like it had my API key in it. But it's there.

[hannesrudolph]

Would you mind including the entire response with your api key replaced with xxxx? This way we can get Roomote to handle it without additional scoping.