Owen Boyd
10/11/2025, 10:07 PM@flow(timeout_seconds=10 * 60)
def run_table_parser_and_filter(config: TableParserInput) -> TableParserOutput:
@task(timeout_seconds=5 * 60)
def aws_table_parser_batch(config: TableParserInput) -> TableParserOutput:
Marvin
10/11/2025, 10:07 PMMarvin
10/11/2025, 10:10 PMtimeout_seconds
only applies to that task run; it cannot extend or override the parent flow run’s timeout_seconds
. Likewise, a subflow can set its own timeout_seconds
, but when invoked as a subflow it’s still bounded by the parent flow’s timeout. If the parent flow hits its timeout, any running tasks or subflows are terminated.
A couple common gotchas that can look like “the subflow is using the task timeout”:
- If you call a subflow from inside a task, the task’s timeout will kill the subflow when the task times out. Best practice is to call subflows from flows (not from tasks).
- If a task inside the subflow has a shorter timeout, the subflow will fail when that task times out even if the subflow’s (or parent’s) timeout is longer.
What to do instead:
- If you need more time overall, raise or remove the parent flow’s timeout_seconds
.
- If you want the subflow to be truly independent of the parent’s timeout, trigger it as its own deployment (e.g., with run_deployment
) and optionally decide whether to wait for it with a separate wait timeout.
You can distinguish what’s timing out by the error type in your logs:
- Flow timing out: FlowRunTimeoutError
https://github.com/PrefectHQ/prefect/tree/main/src/prefect/flow_engine.py
- Task timing out: TaskRunTimeoutError
https://github.com/PrefectHQ/prefect/tree/main/src/prefect/task_engine.py
If you can share:
- How the subflow is invoked (directly from the parent flow vs. from within a task)
- The exact exception in the logs (FlowRunTimeoutError
vs TaskRunTimeoutError
)
- The decorators on the parent flow, subflow, and task
…I can point to the precise fix.