mirror of
https://github.com/run-llama/llama_deploy.git
synced 2026-08-24 21:01:26 -04:00
Timeout for nested network workflows fixed at 120 seconds #161
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Tehsmash on GitHub (Jan 22, 2025).
The NetworkWorkflow which is used to allow workflows to use other services/workflows in Llama deploy uses the AsyncLlamaDeployClient this client has a default timeout of 120 seconds which is used both as a request timeout to the llama deploy control plane, and as the timeout for session.run(...).
There is currently no way to override this so even when talking to a downstream service with a longer timeout it caps the request at 120 seconds.
When issuing a task to llama deploy perhaps the Client should pick up the timeout from the service i.e. if WorkflowA's configured timeout is 60 seconds, when issuing a request to that service the default wait_for should be 60 seconds?
Alternatively (and I think this might influence the Workflow API) workflow.run(...) should take a timeout as an override for the default timeout in the workflow. That way the session.run(..) API can also take a timeout and remain compatible. So then different calls to nested workflows at different points in a parent workflow could specify different timeouts.
@masci commented on GitHub (Jan 24, 2025):
I think re-using the same timeout in NetworkWorkflow to also set the timeout for the inner client is a fair assumption to make, opening a PR with this approach.