New Feature: Enhanced Error Handling for Gemini resourceExhausted in ADK
#3812
MarzoukiAziz
started this conversation in
General
Replies: 5 comments 1 reply
|
Completely agree. ADK really needs proper handling for those persistent Gemini 429 errors. It’s the one issue still holding me back from pushing my agent into production. Edit: passing HttpRetryOptions doesn't seem to do anything for this specific error. |
0 replies
|
encoutering the same issue |
0 replies
|
Second this highly ! would be really good to know the source of such a problem . |
0 replies
|
We have about 70+ agents, ready to go to production, but stakeholders arw scared because of this |
0 replies
|
We recently updated our docs on how one could manage 429s: https://google.github.io/adk-docs/agents/models/#error-code-429-resource_exhausted |
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
💡 New Feature: Enhanced Error Handling for Gemini
resourceExhaustedin ADKDescription .
I'm frustrated when I encounter a
resourceExhaustederror while using the Gemini API through the Google ADK, and the application provides no clear, programmatic way to handle this situation gracefully or inform the user effectively. This typically happens when the user's quota limit for the Gemini API has been reached. Currently, this can lead to a poor user experience, as the api fail immediately.Solution
To implement a retry-based solution for the resourceExhausted error without immediately cutting the stream, you should first specifically detect the quota-related error from the ADK's response, then initiate a series of escalating retries using exponential backoff to temporarily pause the interaction instead of terminating it immediately, informing the user that the service is busy and trying again shortly; if these retries fail, the system should gracefully degrade by either switching to a less resource-intensive Gemini model or disabling resource-heavy features within the current user session, only terminating the stream as a last resort when all other recovery attempts are exhausted.
All reactions