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

bug: failed sync controller prevents subsequent startup retries

Aperta
  • Qualcosa non va?
#190 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

@Sarthak-Shreshtha01 ci sta già lavorando.

Dal 8/10/2026.

  • #191 di @Sarthak-Shreshtha01 — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
20/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
go
Ambito
distributed-systems

Direzione di ricerca

Review the DynamicMultiClusterManager.runnables, syncCancels, and ensureSyncController entry points to understand controller startup and cache sync timeout handling. Reproduce a cache sync timeout, then verify synchronization resumes after API access is restored without restarting the agent.

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

Descrizione

kind/bug
Describe the bug

When a sync controller fails during startup, it is removed from DynamicMultiClusterManager.runnables, but its entry remains in the sync manager's syncCancels map.

Subsequent calls to ensureSyncController() for the same PublishedResource UID/resourceVersion find this stale entry and return an empty result and nil error without creating a replacement controller.

The controller has stopped, but the sync manager still considers it present.

Steps To Reproduce
  1. Run the agent with an enabled PublishedResource and verify that an annotation update on an existing object in kcp propagates to the service cluster.
  2. Restart the agent with a temporary proxy that returns HTTP 503 for LIST/WATCH requests to that resource in the service cluster. Keep API discovery and other API requests available.
  3. Keep those requests blocked for longer than the controller's cache sync timeout. In this test, requests were blocked for 180 seconds.
  4. Observe Controller failed to start with a cache sync timeout error.
  5. Restore API access without restarting the agent or modifying the PublishedResource.
  6. Update the annotation on the same object in kcp.
  7. Observe that the update does not propagate to the service cluster and no replacement sync controller is created. Confirm that the PublishedResource's resourceVersion is unchanged.
  8. Restart the agent and observe that the pending annotation update propagates.
Expected Behaviour

When a sync controller fails during startup, the sync manager should clear the failed controller's registration and retry startup with backoff.

Once API access is restored, synchronization should resume without restarting the agent or modifying the PublishedResource.

Additional Context

Related: #182 concerns old controllers remaining active after PublishedResource updates. This report concerns failed controllers preventing subsequent startup retries.

Lingua principale
Go
Stelle
25
Fork
31
Merge medio
5g 18h
PR unite (30g)
1

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 kcp-dev/api-syncagent

Tutte le issue di kcp-dev/api-syncagent

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.