anor4k opened a new pull request, #72030: URL: https://github.com/apache/airflow/pull/72030
# Why `DataprocSubmitJobOperator(deferrable=True)` does not enforce `execution_timeout`. Once the operator defers, the synchronous `execute()` returns, and nothing bounds the deferral: `self.defer()` is called without a `timeout`, so the trigger polls the job forever. Even when a user passes `defer(timeout=...)` through a subclass, a framework-level trigger timeout resumes the task only to fail it — the Dataproc job itself keeps running, because the triggerer does not run the trigger's `on_kill` for a timeout resume. In non-deferrable mode, exceeding `execution_timeout` raises `AirflowTaskTimeout` and `on_kill()` cancels the job. Deferrable mode silently loses both behaviors. The framework gap is acknowledged by `# TODO: handle timeout in case of deferral` in `task-sdk/src/airflow/sdk/execution_time/task_runner.py`. This is the same class of issue already fixed for `DbtCloudRunJobOperator` (#61467 → #66449), `AirbyteTriggerSyncOperator` (#64048 → #64051), and `KubernetesPodOperator` (#67227 → #67229). # What Mirrors the approach merged in #67229: - **Operator** (`dataproc.py`): when `execution_timeout` is set, derive an absolute deadline anchored on `ti.start_date` (stable across re-deferrals) and pass it to `DataprocSubmitTrigger` as `execution_deadline`. Also pass `timeout=` to `self.defer()` as a framework backstop, with one polling interval of slack so the trigger's own deadline handling (which cancels the job) fires first. - **Trigger** (`triggers/dataproc.py`): `DataprocSubmitTrigger` accepts an optional `execution_deadline` (epoch seconds). When the deadline passes while the job is still running, the trigger cancels the Dataproc job (unless `cancel_on_kill=False`) and emits a `TIMED_OUT` event. - **`execute_complete`**: raises `AirflowException` on the `TIMED_OUT` event, failing the task. `generated/known_airflow_exceptions.txt` is bumped for the one new `raise AirflowException` (only the dataproc line; the file has unrelated drift on main that a full `--generate` would also pick up). Behavior is unchanged when `execution_timeout` is not set (`execution_deadline=None`, no defer timeout). `DataprocSubmitJobDirectTrigger` (start-from-trigger path) has the same gap and could be handled in a follow-up. # Tests - Trigger: deadline expiry cancels the job and yields `TIMED_OUT`; `cancel_on_kill=False` skips the cancel; serialization includes `execution_deadline`. - Operator: deferral carries the computed deadline and a defer timeout; `execute_complete` raises on `TIMED_OUT`. ``` providers/google/tests/unit/google/cloud/triggers/test_dataproc.py -k TestDataprocSubmitTrigger: 7 passed, 2 skipped providers/google/tests/unit/google/cloud/operators/test_dataproc.py -k TestDataprocSubmitJobOperator: 22 passed ``` --- ^ Add meaningful description above Read the **[Pull Request Guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#pull-request-guidelines)** for more information. In case of fundamental code changes, an Airflow Improvement Proposal ([AIP](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals)) is needed. In case of a new dependency, check compliance with the [ASF 3rd Party License Policy](https://www.apache.org/legal/resolved.html#category-x). In case of backwards incompatible changes please leave a note in a newsfragment file, named `{pr_number}.significant.rst` or `{issue_number}.significant.rst`, in `airflow-core/newsfragments`. -- 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]
