githttp: remove a stale ref lock automatically when no git can own it
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
調査の方向性
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分
- マージ済み PR（30日）
- 243
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- 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 1週間以上 初心者へのやさしさ 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 接入参考文档対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン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 日以内に返信