githttp: remove a stale ref lock automatically when no git can own it
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Read the history of #485, especially commits f32e9ac1 to 76d8cd18, and the repo's hydration and ref update paths, including syncRefsPassUpdates. Compare the proposed hydrate-lock and open-file-descriptor approaches, accounting for linked worktrees and processes the scan cannot read. Done means a chosen design safely removes stale ref locks, with tests covering the ownership cases described in the issue.
由索引模型根据 Issue 内容生成。
描述
#485 lands only detection for stale ref locks (#464): hydration logs each lock older than 1 minute that blocks a failed ref update, and deploy-production.md gives a manual runbook (stop the replica, check for Git processes, remove the lock). A replica hit by #464 stays unable to serve that repository until an operator acts.
This issue tracks an automatic, safe removal. Three Codex review rounds on #485 showed that a /proc scan for "no process works in the repository" is hard to make complete:
- Hydration's own read-only
for-each-refchildren run in the repository while a batch flushes: the deletion pass and the update pass (syncRefsPassUpdates) both have one. The check must exclude each of them, or it refuses cleanup on large syncs (fails safe, but the node stays wedged). - A git process can reach the cache through a linked worktree or
GIT_COMMON_DIR, so its cwd, argv andGIT_DIRdo not name the cache repository. - Processes the scan cannot read (another user's process,
hidepid, another PID namespace that shares the cache volume) must count as possible owners.
Possible approaches: hold the repository's hydrate lock in every git that can take a cache-repo ref lock, so hydration can prove no owner exists without scanning /proc; or check open file descriptors for the lock file. The closed approach and its tests are in the history of #485 (commits f32e9ac1 to 76d8cd18).
Trigger: a report of a replica stuck on ref lock … blocks ref updates, or a decision to make cache repos self-healing.
Refs #464
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high
- 主要语言
- Go
- 星标
- 0
- 派生
- 0
- 平均合并
- 6 小时 16 分钟
- 30 天内合并 PR
- 243
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
coder/openstorage 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
coder/openstorage#807 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 49/100
coder/openstorage#806 ·
维护者通常 1 天内回复
-
api: merge/preview ignores strategy, squash and allow_unrelated_histories可能已有人在做 @ThomasK33 今天认领。 未关闭
难度 4/5 3-5 天 新手友好度 35/100
coder/openstorage#805 ·
维护者通常 1 天内回复
-
githttp: +import remote serves clone and fetch, and its pushes stay out of the normal branch list可能已有人在做 @ThomasK33 今天认领。 未关闭
难度 5/5 一周以上 新手友好度 20/100
coder/openstorage#804 · 2 条评论 ·
维护者通常 1 天内回复
-
api: branches/create ignores expected_target_sha, so a guarded create or move can overwrite a branch可能已有人在做 @ThomasK33 今天认领。 未关闭
难度 4/5 3-5 天 新手友好度 35/100
coder/openstorage#803 ·
维护者通常 1 天内回复
查看 coder/openstorage 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 86/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
coder/coder-logstream-kube#255 · 1 条评论 ·
-
[FEATURE]: 录入 AIDEV Agent Package v1 接入参考文档可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭kind/features
难度 2/5 1-3 小时 新手友好度 73/100
TencentBlueKing/bk-nodemgr#3991 ·
维护者通常 1 天内回复
-
meta
难度 2/5 1-3 小时 新手友好度 62/100
last9/last9-mcp-server#554 ·
维护者通常 1 天内回复