amoghrajesh commented on code in PR #71211: URL: https://github.com/apache/airflow/pull/71211#discussion_r3756690354
########## providers/amazon/docs/operators/glue.rst: ########## @@ -139,6 +139,79 @@ To submit a new AWS Glue job you can use :class:`~airflow.providers.amazon.aws.o The same AWS IAM role used for the crawler can be used here as well, but it will need policies to provide access to the output location for result data. +Durable execution +================== + +``GlueJobOperator`` submits a job run and then polls it to completion on the worker. By default +the operator runs in a *durable* mode that makes this crash-safe: the Glue job run id is +persisted to :doc:`task state store <apache-airflow:core-concepts/task-state-store>` before +polling begins, so if the worker crashes or is preempted and the task is retried, the operator +reconnects to the run that is already executing in Glue instead of starting a new one. + +This matters more for Glue because a Glue job's ``concurrent_run_limit`` defaults to ``1``, so +submitting a second run while the first is still active does not create a harmless duplicate, it +fails outright with ``ConcurrentRunsExceededException`` and the task keeps retrying against a run +it can never see. Durable execution turns that retry into a normal reconnect. + +On retry the operator checks the prior run's state: + +* if it is still starting, running, waiting for capacity, or being stopped, the operator + reconnects and continues polling +* if it already succeeded, the operator returns immediately without resubmitting +* if it stopped, failed terminally, or its id has expired and is no longer found, the operator + submits the job fresh + +A stopped run resubmits rather than being treated as a success. Glue's API has no way to tell a +run that was cancelled manually (for example, in the AWS console) apart from one this operator's +own :meth:`~airflow.providers.amazon.aws.operators.glue.GlueJobOperator.on_kill` stopped, which +happens whenever ``stop_job_run_on_kill=True`` and the task is killed -- on SIGTERM, on +``execution_timeout``, or when the task is cleared while running. Since the two cases can't be +told apart, a stopped run always resubmits, so a self-inflicted stop never gets silently reported +as a false success. + +This protection also applies when ``wait_for_completion=False`` -- even though that task attempt +never polls at all, a retry after a successful submission still reconnects rather than +resubmitting, since the run id is persisted immediately after submission regardless of whether the +task waits for it to finish. + +Durable execution requires Airflow 3.3 or newer for the task state store lookup above. On earlier +Airflow versions, or if the task state store is unavailable at runtime, ``durable=True`` still Review Comment: Reworded to name the two cases that actually fall through (no store, or nothing recorded yet), rather than "unavailable" implying it covers the store-errors case too, which it doesn't. -- 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]
