[BUG] InstanceSet readiness ignores configured identities and current runtime timing

Open
  • Is something wrong?
#11,030 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@leon-ape is already working on this.

Since Oct 27, 2026.

  • #11027 by @leon-ape — open

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
go, kubernetes
Domain
backend, databases

Research direction

The implementation is tracked in linked PR #11027, which includes both readiness producers, condition publication and retry scheduling, the Component time consumer, API documentation, and regression tests. Start by reviewing that PR and the listed affected package suites to understand the controller and runtime timing changes. The issue describes the required readiness behavior and validation; the work is already under way.

Written by the indexing model from the issue text.

Description

kind/bug
Description

InstanceSet aggregate Ready and Available use the number of observed members as their requirement. A positive configured target can therefore appear healthy with missing identities, a healthy subset, or no running members after Stop. Available in Instance mode can also reflect an obsolete child MinReadySeconds policy.

Aggregate Ready can remain True across an unobserved runtime replacement. Its LastTransitionTime then does not prove that the current Pod has had the existing 60-second role-probe window.

Required behavior
  • The replica requirement is spec.replicas, defaulting to one. Use the existing configured member allocation to identify the required members. Extra members cannot replace missing targets or independently block aggregate readiness.
  • Ready requires every assigned member to exist and be healthy. Available requires those members to be Ready for the current InstanceSet MinReadySeconds, measured from their actual runtime Ready times.
  • Stop preserves a positive replica requirement. Healthy members can remain Ready immediately after Stop is submitted; partial or completed stopping is not ready when fewer than the required members remain healthy. Start must restore all required members.
  • Explicit replicas=0 reports Ready=True and Available=True even while extra members await cleanup. Runtime counts, fault reporting, cleanup, and operation completion remain separate.
  • Condition LastTransitionTime changes only when that condition's Status changes. Generation, Reason, and Message changes preserve it. Each condition's observedGeneration identifies the spec evaluated.
  • Persist a changed readiness observation before this controller's repair actions can erase the observed gap. Stable False/Unknown must still permit recovery. Availability waiting must not prevent assistant, alignment, or update work.
  • The Component time consumer must validate current aggregate readiness and current Pod/runtime time evidence before using the existing role timeout.

Ready does not add desired-revision, config-application, role, or operation-completion requirements. Existing convergence APIs, Component policies, lifecycle checks, update budgets, and Ops outcomes retain their own gates.

Implementation and validation

Tracked in #11027 for main only, with no backport or new public API fields. The PR includes both producers, narrow condition publication and retry scheduling, the Component time consumer, API documentation, and regressions.

Ten affected/downstream package suites and full make lint pass locally. Controller fault tests use fake storage and actual controller entry paths. The Component premature-timeout regression was reproduced before the fix. No real-cluster or multicluster Component/Ops end-to-end result is claimed. Stable Unknown progression is covered with an injected evaluator; a reachable incomplete flat allocation was not established under current validation.

Source context

Orchestrator start report. The historical runtime trace still needs confirmation before attributing every reported early Component failure to these defects.

Related #10987, #10995, and #11003 concern the Start investigation and Component start handling.

Dominant language
Go
Stars
3.1k
Forks
282
Avg merge
1d 4h
Merged PRs (30d)
61

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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 apecloud/kubeblocks

All issues in apecloud/kubeblocks

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.