Document Best Practice for Long Running Invocation
- Dominant language
- Shell
- Stars
- 1.5k
- Forks
- 1.3k
- Avg merge
- 7d 1h
- Merged PRs (30d)
- 34
Description
In some production scenarios, I may have an agent that could take like 2 hours to run if it does something especially complex.
I'm curious what the best practice is for handling this, especially given that the adk is a fast api app under the hood, which I don't really associate with long running asynchronous jobs.
AFAIK, there is no job queue or anything like that which would allow an agent to pick up where it left off after working for 1h if my adk instance went down or got rolled to a new deployment or whatever.
I would like to understand the best way to solve this problem with this framework.
For example...
Should I split agents into tasks that only take 30m to run, invoke them always with the run sse endpoint so they are connected to a streaming client that keeps the app alive for long running invocation, and then use something like prefect/airflow/temporal to orchestrate running the different steps, since they support persistent queues with retry etc
An alternative is to just stream the agent results and assume fast API app wont respond to any sigterm that would kill the client. That feels nowhere near robust enough to me for a production app doing fancy stuff.
Contributor guide
Assessment
This issue has not been assessed yet.