This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/main by this push:
new bda84d19fa3 Document that clear_on_success also removes the KPO pod
identity (#71749)
bda84d19fa3 is described below
commit bda84d19fa38178f0234c357cbdc412c87821d96
Author: 秀吉 <[email protected]>
AuthorDate: Mon Sep 21 01:18:29 2026 +0800
Document that clear_on_success also removes the KPO pod identity (#71749)
* Document that clear_on_success also removes the KPO pod identity
The durable execution section says the persisted pod identity is only
removed by `airflow state-store clean`, but `[state_store]
clear_on_success` clears the whole task scope as soon as the task
instance succeeds. It is off by default, so the sentence holds for most
deployments but not for the ones that turn it on.
Generated-by: Claude Code following
https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions
Signed-off-by: thc1006 <[email protected]>
* Tighten the clear_on_success wording and link the task state store docs
Review nits: reflow the paragraph so the retry_delay sentence no longer
leaves an orphan line, and point readers at the core task state store
docs for the setting.
Generated-by: Claude Opus 5
---------
Signed-off-by: thc1006 <[email protected]>
Co-authored-by: Jarek Potiuk <[email protected]>
---
providers/cncf/kubernetes/docs/operators.rst | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/providers/cncf/kubernetes/docs/operators.rst
b/providers/cncf/kubernetes/docs/operators.rst
index f5e19c27a7a..8ee0e3bec36 100644
--- a/providers/cncf/kubernetes/docs/operators.rst
+++ b/providers/cncf/kubernetes/docs/operators.rst
@@ -222,14 +222,15 @@ ignored either way. The deprecated
``reattach_on_restart`` parameter (default ``
only lever there, and it falls back to the same label-search reattach behavior
this operator has
always used -- unchanged from before this feature existed.
-The pod identity persisted in task state store isn't deleted automatically,
that only happens
-when someone runs ``airflow state-store clean``. If a task's ``retry_delay``
is longer than
-``[state_store] default_retention_days`` (30 days by default) and cleanup runs
in between, the
-pod identity won't be there for the next retry, and the operator falls back to
the label-search
-bootstrap path instead of reconnecting directly. This isn't necessarily a
duplicate, the label
-search can often still find the same pod, but it loses the unambiguous
reconnect and reopens
-exposure to ``FoundMoreThanOnePodFailure`` if a genuine duplicate pod exists
by then. Avoid
-running cleanup on a schedule shorter than your longest ``retry_delay``.
+The persisted pod identity is only removed by ``airflow state-store clean``
(retention-based) or,
+when ``[state_store] clear_on_success`` is enabled (``False`` by default),
automatically as soon as
+the task instance succeeds -- see the :doc:`task state store
<apache-airflow:core-concepts/task-state-store>`
+docs. If a task's ``retry_delay`` is longer than ``[state_store]
default_retention_days`` (30 days by
+default) and cleanup runs in between, the pod identity won't be there for the
next retry, and the
+operator falls back to the label-search bootstrap path instead of reconnecting
directly. This isn't
+necessarily a duplicate, the label search can often still find the same pod,
but it loses the
+unambiguous reconnect and reopens exposure to ``FoundMoreThanOnePodFailure``
if a genuine duplicate
+pod exists by then. Avoid running cleanup on a schedule shorter than your
longest ``retry_delay``.
``durable`` supersedes the deprecated ``reattach_on_restart`` parameter on
Airflow 3.3+, where
passing ``reattach_on_restart`` still works and maps its value onto
``durable``. Below 3.3,
