@Marvin what is the default task timeout on prefect 2?

In Prefect 2, tasks don't have a default timeout. If you want to specify a timeout, you need to use the

timeout_seconds

keyword argument when defining a task. This allows you to set a specific duration in seconds after which a task will timeout if it's still running. Here's an example:

python
from prefect import task

@task(timeout_seconds=60)
def my_task():
    # task logic here

In this case, if

my_task

runs for more than 60 seconds, it will be terminated and marked as timed out. More details can be found here. It's up to you to save your tasks from running indefinitely!

@Marvin if no timeouts are specified how is this error occuring?

Finished in state Failed('Flow run encountered an exception. TimeoutError: ')
01:23:28 PM
prefect.flow_runs
Encountered exception during execution:
Traceback (most recent call last):
  File "/app/.venv/lib/python3.11/site-packages/prefect/engine.py", line 864, in orchestrate_flow_run
    result = await flow_call.aresult()
             ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/.venv/lib/python3.11/site-packages/prefect/_internal/concurrency/calls.py", line 293, in aresult
    return await asyncio.wrap_future(self.future)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TimeoutError

The TimeoutError you're encountering, despite not setting a specific timeout for your task, can be attributed to other factors within the Prefect framework, especially in complex flow setups. Here's what might be happening: 1. Default Timeout in Framework: Sometimes, internal operations or sub-components within Prefect might have implicit timeouts configured. This could originate from network operations, resource allocations, or specific integrations. 2. Concurrency and Deadlocks: Recent updates to Prefect (see this PR) address issues with deadlocks and cancellation contexts, which might affect timeout handling. If a deadlock is detected, Prefect might trigger a TimeoutError as a protective measure. 3. Subflow Errors: If you have subflows or tasks that crash or go into non-responsive states, the overarching flow might register it as a TimeoutError. This was discussed in an issue where flows with crashed subflows led to unexpected flow states and timeouts (detailed in this GitHub issue). In your situation, examine the structure of your flow and any nested subflows or dependencies that could be introducing implicit time constraints or resource locks. This might not be as fatalistic as Marvin might assume, but a few adjustments should stabilize things!