Enforce execution_timeout in deferrable DataprocSubmitJobOperator

[anor4k]

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 for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
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.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[anor4k]

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 for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
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.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[anor4k]

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 for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
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.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[anor4k]

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 for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
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.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[anor4k]

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 for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
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.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[anor4k]

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 for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
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.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[anor4k]

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 for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
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.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[anor4k]

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 for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
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.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack