Runner end callbacks time out error

[ruqianq]

Hi all,

I’m experimenting with after_run_callback in a custom plugin.
My goal: after an agent run finishes, I call an external API to process about 100 rows in a DataFrame, then post results back.

The problem:
The callback consistently hits a timeout error (message says default is set to 5 s).
I haven’t found a way to override or pass None to the timeout parameter.

My questions:
Is there a supported way to change or disable the 5 s timeout for runner-end callbacks?
What patterns are recommended if I need to run heavier post-processing right after the runner finishes? and the hard requirement is it has to run with my agent workflow
Or is there a built-in mechanism for “post-run jobs” other than the callbacks?

Any guidance or examples would be greatly appreciated. Thanks! 🙏

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: The after_run_callback is intended for lightweight cleanup and logging, not for long-running tasks, which is why you're likely seeing a timeout. The recommended approach for your use case is to use a LongRunningFunctionTool, which is specifically designed to handle heavy or long-running jobs that need to integrate with an agent's workflow.

---

Hi @ruqianq,

Thanks for your detailed question. It highlights an important aspect of working with ADK's lifecycle and plugins.

after_run_callback and Timeouts

The after_run_callback is designed as the final step in the ADK lifecycle, primarily for teardown, final logging, or reporting tasks that are lightweight and can execute quickly. It is not intended for heavy processing or long-running I/O operations like calling an external API for a significant number of rows. While the documentation doesn't specify a user-configurable timeout for this callback, its design for quick cleanup actions explains why a timeout would be in place to prevent blocking the finalization of the agent run.

Recommended Pattern for Heavy Post-Processing

For your requirement of running a heavier post-processing task that is still connected to the agent's workflow, the recommended and built-in ADK pattern is to use a LongRunningFunctionTool. [1]

Here’s how it would work for your use case:

1. Create a LongRunningFunctionTool: Instead of putting your API call logic in the callback, you would wrap it in a LongRunningFunctionTool. This tool is designed to start a task, allow the agent run to pause or complete, and then be polled for results.
2. Initiate the Task: Your agent would call this tool, which then starts the process of calling your external API for the 100 rows.
3. Pause and Poll: The tool can immediately return a task ID. The agent run can then conclude. An external client or another part of your application can then poll a separate endpoint to check the status of this long-running task.
4. Continue the Workflow: Once the external API processing is complete and the results are ready, the client can start a new agent run, providing the results as input to continue the workflow.

This approach aligns perfectly with your hard requirement for the process to run with your agent workflow, as it provides a formal, stateful way to handle tasks that extend beyond a single, synchronous agent run.

Alternative: Asynchronous Decoupling

Another pattern, if you don't need to feed the results immediately back into the same agent run, is to fully decouple the task. Your after_run_callback could create an asyncio task (e.g., using asyncio.create_task) to handle the API call in the background. The callback would return immediately, avoiding the timeout, while your processing happens independently. This is a good option if the post-processing result is for external reporting or storage and doesn't need to alter the agent's state.

In summary, for deep integration with the agent workflow, the LongRunningFunctionTool is the most robust and recommended solution. [1]

[1] https://google.github.io/adk-docs/tools/function-tools/