Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

bug: failed sync controller prevents subsequent startup retries

Ouverte
  • Quelque chose ne va pas ?
#190 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

@Sarthak-Shreshtha01 y travaille déjà.

Depuis le 8/10/2026.

  • #191 par @Sarthak-Shreshtha01 — ouverte

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
20/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
go
Domaine
distributed-systems

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Go
Étoiles
25
Forks
31
Aucune PR mergée en 30 j

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de kcp-dev/api-syncagent

Toutes les issues de kcp-dev/api-syncagent

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.