Skip to content

Document that clear_on_success also removes the KPO pod identity #71749

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
potiuk merged 2 commits into from
Sep 20, 2026
Merged

Document that clear_on_success also removes the KPO pod identity #71749

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7e3a174
Document that clear_on_success also removes the KPO pod identity
thc1006 Aug 17, 2026
ac18eea
Tighten the clear_on_success wording and link the task state store docs
potiuk Sep 20, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 9 additions & 8 deletions providers/cncf/kubernetes/docs/operators.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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,
Expand Down