8000 fix(chk): prevent tight reconcile loop on status updates by Tyagiquamar · Pull Request #2111 · Altinity/clickhouse-operator · GitHub
[go: up one dir, main page]

Skip to content

fix(chk): prevent tight reconcile loop on status updates - #2111

Open
Tyagiquamar wants to merge 1 commit into
Altinity:masterfrom
Tyagiquamar:fix/chk-reconcile-loop-predicate-2107
Open

Tyagiquamar wants to merge 1 commit into
Altinity:masterfrom
Tyagiquamar:fix/chk-reconcile-loop-predicate-2107

Conversation

@Tyagiquamar
@Tyagiquamar Tyagiquamar commented Oct 21, 2026 •
Copy link
Copy Markdown

Summary

A ClickHouse Keeper status-only update no longer requeues the installation and tight-loops the reconciler.

Root cause

The keeper predicate treated every update as work, including a status write that left generation, finalizers, and deletionTimestamp unchanged. The reconciler then failed to treat an unchanged generation as done, so the status write queued another reconcile.

Solution

The predicate drops that pure status update. Reconcile returns immediately when the generation is unchanged, after the finalizer-install case and before HasReconcileWork.

Test plan

Test_keeperPredicateUpdate covers a pure status update (dropped), a generation change (queued), and a finalizer change (queued).

Fixes #2107

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CHK reconciles in a tight loop after its first Completed; with onKeeperResourceUpdate: reconcile the dependent CHI never finishes (0.27.4)

1 participant

0