New Feature: Enhanced Error Handling for Gemini resourceExhausted in ADK
#3812
Replies: 5 comments
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
encoutering the same issue |
Beta Was this translation helpful? Give feedback.
-
|
Second this highly ! would be really good to know the source of such a problem . |
Beta Was this translation helpful? Give feedback.
-
|
We have about 70+ agents, ready to go to production, but stakeholders arw scared because of this |
Beta Was this translation helpful? Give feedback.
-
|
We recently updated our docs on how one could manage 429s: https://google.github.io/adk-docs/agents/models/#error-code-429-resource_exhausted |
Beta Was this translation helpful? Give feedback.
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.
Beta Was this translation helpful? Give feedback.
All reactions