Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Recover reconciles from recoverAbortedReconcileOnPodReady ignores readiness of service selector labels

Open
#2,106 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go, kubernetes

Research direction

Start at the recoverAbortedReconcileOnPodReady path, which decides whether to restart a reconcile from pod readiness alone. Then check how the clickhouse.altinity.com/ready pod label is set and how the chop-generated service selector depends on it. Reproduce the 1-shard, 2-replica sequence from the issue. Done means a recovered reconcile no longer removes ready replicas from the service, and a test covers the aborted-then-ready case.

Written by the indexing model from the issue text.

Description

When an aborted reconcile triggers a recovery reconcile via recoverAbortedReconcileOnPodReady, it uses the pod readiness state, but does not check if the pod labels have clickhouse.altinity.com/ready=Yes.

The result is the chop-generated service might get into a state without any replicas selected despite at least one replica being available to serve queries.

Steps on what occurred in a 1-shard, 2-replica cluster:

  1. reconcile triggered
  2. 0-0 starts and completes reconciles
  3. 0-1 starts reconcile, label set clickhouse.altinity.com/ready=No and 0-1 is excluded from service.
  4. 0-1 times out and reconcile is aborted
  5. 0-1 pod became ready, but still remains excluded from service
  6. Since 0-1 pod is ready, reconcile recover triggers and starts with 0-0 first making both replicas removed from svc

Operator version: 0.27.4

Dominant language
Go
Stars
2.6k
Forks
579
Avg merge
5d 22h
Merged PRs (30d)
5

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Altinity/clickhouse-operator

All issues in Altinity/clickhouse-operator

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.