LLM Latency Spikes (3-5 min) during Error Handling in Google ADK

[fedorovychh]

When a tool wrote with Google ADK returns a "failed operation" response, the LLM experiences an abnormal delay (3–5 minutes) before attempting to fix parameters or respond. This "infinite thinking" loop occurs specifically after an error is injected into the conversation context.

What are the most effective strategies to prevent the LLM from getting stuck in a "reasoning loop" after a tool failure—is it better to strip the error response to a bare code, or is there a specific ADK configuration to bypass this latency?

[aniruddhaadak80]

From my point of view, the long pause after a tool failure usually means the model is being given too much ambiguous error context and is trying to reason its way out of an ill-posed repair loop. Bare error codes alone are often too little, but raw stack-like failure prose is often too much.

The most effective pattern is usually a short structured error contract with retryability, suggested parameter corrections, and a hard cap on repair attempts so the agent cannot think in circles for minutes.

[fedorovychh]

From my point of view, the long pause after a tool failure usually means the model is being given too much ambiguous error context and is trying to reason its way out of an ill-posed repair loop. Bare error codes alone are often too little, but raw stack-like failure prose is often too much.

The most effective pattern is usually a short structured error contract with retryability, suggested parameter corrections, and a hard cap on repair attempts so the agent cannot think in circles for minutes.

Okay, I'm going to test few cases and debug to find out how much context LLM gets after tool returns error response. It definitely can be the solution to properly handle errors.

I will let you know after getting results. Thank you for the response!