Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Confirm and fix switchover acknowledgment when no standby exists

Aperta
  • Qualcosa non va?
#835 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
30/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
openapi, postgresql, rust
Ambito
api, backend, databases

Direzione di ricerca

Inizia con la definizione OpenAPI per il state PATCH e riproduci i comandi di switchover documentati su un servizio senza standby e su uno che utilizza async HA. Conferma il comportamento del backend e collega il ticket corrispondente del backend; il lavoro è completato quando l’API distingue uno swap effettivo dall’assenza di uno standby applicabile o da uno standby non pronto, senza richiedere alla CLI di fare supposizioni.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

blocked cloud

Blocked on upstream — 2026-09-18

The owner confirmed this needs an upstream API/team change or authoritative contract and has raised the group with the team. Apply/retain the blocked label. This is outside the current CLI implementation queue.

Clear next step: Provide a distinguishable rejection/completion contract for Postgres switchover when no usable standby exists. The CLI wait removal already landed in #834 / #973.

Keep this issue open. Add the upstream ticket or owner response when available; neither a ticket ID nor an individual assignee has been supplied in this discussion. After the upstream answer/fix, revalidate and scope any required library/CLI follow-up. Do not treat a local workaround or previous partial fix as completion of the backend issue.

Earlier scope and evidence (preserved)

Focused scope — 2026-09-15

Deferred until the direction below is resolved.

Keep the upstream API issue focused. A 200 response does not establish that an HA swap happened.

Acceptance criteria

Obtain backend ownership/ticket and a discriminable rejection/completion contract; keep CLI wait removal separate.

Direction needed

Requires backend ownership and API behavior changes outside this repository.

The focused scope above supersedes implementation suggestions and prior pass-specific deferrals below. Completed work and rejected assumptions remain recorded as history.

Original report and earlier audit history

Validated scope and current-PR plan — 2026-09-11

This section records the QA review and the current decision to finalize existing PRs without opening new PRs. It supersedes the proposed routing/fix suggestions in the original report below; the original observations are retained. Central plan: #757.

Disposition

Deferred from this existing-PR finalization pass. Keep the issue open; no new PR is requested now. This is not a resolution, a severity downgrade, or a waiver of release acceptance.

Validation and corrections

Retain as an upstream API investigation. Reported 200/no-op needs backend confirmation; the CLI cannot prove a swap merely from acknowledgement. Link the actual backend ticket. Keep separate from #834’s CLI surface decision and #827’s unrelated PATCH/tag backend defect.

Original QA report

Found in the 2026-09-11 QA sweep of the combined PR stack at d2c37f81, top PR #823, installed release build (package version still 0.4.2). Reproduced behaviour only; no implementation included.

Severity: medium; silent success on a lifecycle command.

Blocked on: Cloud API owners changing the state endpoint's behaviour. Needs a corresponding backend ticket; tracked here so the CLI issue removing --wait (#834) has a pointer.

Observed on 2026-09-11 against a freshly created Postgres service (aws / eu-west-1 / c6gd.large):

clickhousectl cloud postgres switchover "$PG"            # haType=none → 200, exit 0, service object echoed
clickhousectl cloud postgres update "$PG" --ha-type async  # haType flips to async immediately
psql … -c "select inet_server_addr(), pg_postmaster_start_time()"   # 10.24.1.228, 10:35:25
clickhousectl cloud postgres switchover "$PG"            # 200, exit 0
sleep 90; psql … -c "select inet_server_addr(), pg_postmaster_start_time()"   # identical node, identical postmaster

The OpenAPI document for the state PATCH lists only 200/400/500 and no "no standby" or "not applicable" response. Nothing in the response distinguishes "swapped", "not applicable (haType=none)" and "standby not yet ready", so a client cannot tell the user the truth without guessing about server behaviour (which #627 review explicitly rejected).

Expected: a 4xx (e.g. 409) with a discriminable message when there is no standby to switch to, and ideally a response field that identifies the new primary. Once that lands the CLI can classify it structurally like service delete CONFLICT (#673).

Lingua principale
Rust
Stelle
80
Fork
9
Merge medio
4g 13h
PR unite (30g)
59

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ClickHouse/clickhousectl

Tutte le issue di ClickHouse/clickhousectl

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.