bnspopi opened a new pull request, #74655: URL: https://github.com/apache/airflow/pull/74655
A pod name identifies a pod only for as long as that pod exists. #71744 checks the pod uid once, when the identity is read back on durable reattach, and after that both delete paths go on sending name and namespace alone: - `PodManager.delete_pod()` — used by `process_pod_deletion` for `on_finish_action` - `KubernetesPodOperator.on_kill()` — its own `delete_namespaced_pod` call So the sequence #71748 describes is possible: the operator observes pod A, A goes away, a pod B takes the name, and the delete lands on B. The reporter demonstrated exactly this against k8s v1.37.0-rc.0 — the unconditional delete removed the replacement, while the same delete with the remembered uid as a precondition was refused with 409. Both paths now send the observed uid as a delete precondition, built by a shared `pod_uid_precondition()` helper. A pod that was never created has no uid, so the request stays unconditional as it is today. The 409 a failed precondition returns is handled rather than retried. That matters because 409 is in `TRANSIENT_STATUS_CODES`, so `generic_api_retry` would otherwise back off and retry a request that can never succeed — the name belongs to a different pod, and the one the call was about is already gone. `delete_pod` treats it like the 404 it already tolerates; `on_kill` logs it at info instead of an exception traceback. Tests: - `test_delete_pod_pins_the_request_to_the_observed_pod` (parametrized over a created and a never-created pod) - `test_delete_pod_treats_a_failed_precondition_as_already_deleted`, which also pins that it is not retried - `test_pod_uid_precondition_without_metadata` - `test_on_kill_pins_the_delete_to_the_pod_it_started` and `test_on_kill_leaves_a_replaced_pod_alone` Not in this PR — the other half of #71748: `KubernetesPodTrigger` carries only `pod_name` and `pod_namespace`, so a deferred task's polls and its final log read can still hit a replacement, and the async `KubernetesHook.delete_pod()` has no uid to pass. Fixing that means adding the uid to the trigger's constructor and `serialize()`, which is a serialization change with its own backwards-compatibility questions for triggers already in flight. Worth doing, but it deserves its own review rather than riding along with the delete fix. I could not run the provider test suite on this machine, so the first run will be CI here; happy to follow up on anything it flags. related: #71748, #71744, #71743 --- ##### Was generative AI tooling used to co-author this PR? - [X] Yes (Claude Code) Generated-by: Claude Code following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) --- * Read the **[Pull Request Guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#pull-request-guidelines)** for more information. Note: commit author/co-author name and email in commits become permanently public when merged. * When adding dependency, check compliance with the [ASF 3rd Party License Policy](https://www.apache.org/legal/resolved.html#category-x). -- 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]
