githttp: remove a stale ref lock automatically when no git can own it

Đang mở
  • Có gì không ổn?
#490 4 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
git, go
Lĩnh vực
backend, devops

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

#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:

  1. Hydration's own read-only for-each-ref children 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).
  2. A git process can reach the cache through a linked worktree or GIT_COMMON_DIR, so its cwd, argv and GIT_DIR do not name the cache repository.
  3. 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

Ngôn ngữ chính
Go
Star
0
Fork
0
Merge trung bình
6 giờ 16 phút
Pull request đã merge (30 ngày)
243

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của coder/openstorage

Tất cả issue của coder/openstorage

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.