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

Aperta
  • Qualcosa non va?
#490 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
git, go
Ambito
backend, devops

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

#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

Lingua principale
Go
Stelle
0
Fork
0
Merge medio
6h 16m
PR unite (30g)
243

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di coder/openstorage

Tutte le issue di coder/openstorage

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.