bug: failed sync controller prevents subsequent startup retries
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 20/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 停滞
- 技术栈
- go
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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
- Run the agent with an enabled PublishedResource and verify that an annotation update on an existing object in kcp propagates to the service cluster.
- 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.
- Keep those requests blocked for longer than the controller's cache sync timeout. In this test, requests were blocked for 180 seconds.
- Observe
Controller failed to startwith a cache sync timeout error. - Restore API access without restarting the agent or modifying the PublishedResource.
- Update the annotation on the same object in kcp.
- 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.
- 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.
- 主要语言
- Go
- 星标
- 25
- 派生
- 31
- 平均合并
- 5 天 18 小时
- 30 天内合并 PR
- 1
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
kcp-dev/api-syncagent 的其他 Issue
-
kind/bug
难度 2/5 1-3 小时 新手友好度 74/100
kcp-dev/api-syncagent#163 ·
-
难度 2/5 1-3 小时 新手友好度 78/100
kcp-dev/api-syncagent#161 ·
-
bug: dangling schema in an APIExport is neither removed nor reported可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 4/5 3-5 天 新手友好度 55/100
kcp-dev/api-syncagent#188 · 1 条评论 ·
-
kind/feature
难度 4/5 3-5 天 新手友好度 48/100
kcp-dev/api-syncagent#186 · 1 条评论 · 1 个 reaction ·
-
bug: PublishedResource updates leave previous sync controllers active可能重新可做 @adoi 于 85 天前认领，目前没有进行中的 PR。 未关闭kind/bug
kcp-dev/api-syncagent#182 · 1 条评论 · 已指派 1 人 ·
查看 kcp-dev/api-syncagent 的全部 Issue
相似的 Issue
-
agent-review-finding bug
难度 2/5 1-3 小时 新手友好度 68/100
jordansmall/spindrift#5281 ·
维护者通常 1 天内回复
-
unbounded value for n in `/v1/logs` can panic/OOM可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭small item
难度 2/5 1-3 小时 新手友好度 72/100
canonical/pebble#1127 · 2 条评论 ·
维护者通常 1 天内回复
-
[schema-coverage] elasticstack_elasticsearch_synonym_set (data source)可能已有人在做 @github-actions 今天认领。 未关闭acceptance-tests phase-coding schema-coverage testing triaged
难度 2/5 1-3 小时 新手友好度 81/100
elastic/terraform-provider-elasticstack#5211 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 89/100
open-policy-agent/opa#9366 · 1 个 reaction ·
维护者通常 1 天内回复
-
defect
难度 2/5 1-3 小时 新手友好度 78/100
nats-io/nats-server#8752 ·
维护者通常 1 天内回复