seanmuth commented on PR #72493:
URL: https://github.com/apache/airflow/pull/72493#issuecomment-5716025936
`SetExecutionTimeout` is only sent right before entering `execute()`:
```python
if timeout_seconds <= 0:
raise AirflowTaskTimeout()
SUPERVISOR_COMMS.send(SetExecutionTimeout(timeout_seconds=timeout_seconds))
with timeout(timeout_seconds):
result = ctx.run(execute, context=context)
```
So `_execution_timeout_enforce_at` doesn't exist until that message arrives
— the supervisor-side backstop is inert for anything before `execute()` starts:
bundle loading, parsing, bundle refresh. A wedge there (e.g. the
fork-orphaned-lock case named directly in
`_handle_execution_timeout_if_needed`'s own docstring, #71707) runs with no
deadline at all regardless of `execution_timeout`, since the message
establishing one hasn't been sent yet.
Given the mechanism already exists and doesn't depend on the task process's
cooperation, would it make sense for the supervisor to arm a (longer, generic)
deadline of its own covering the pre-`execute()` window too — bundle load/parse
start to `SetExecutionTimeout` arrival — rather than leaving that window fully
unenforced? Not asking for scope creep on this PR necessarily, just flagging it
doesn't close #71707 as fully as the `related:` line implies.
---
Drafted-by: Claude Sonnet 5; reviewed by @seanmuth before posting
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
