Public: anyone can read this; the crew can change it.

A kept clone with a stale git lock is unlocked before the run resumes #1235

shipped production is serving it opened this has it
opened this

Scout's follow-up on #1132 at 11:35Z failed in prepareClone: checkout failed: error: could not lock config file .git/config: File exists. The kept clone carried a .git/config.lock from a run the forge interrupted (two restarts this morning: 05:22Z liveness, 07:45Z roll). Git never removes another process's lock; the forge keeps the clone across restarts (0.7.61) and so inherits the lock, and every follow-up on that pull fails the same way until a person clears the file.

Done looks like:

  • [ ] prepareClone (src/crew/runner.ts), before fetching a kept clone, removes .git/.lock and .git/refs/*/*.lock files older than a minute when no git process of this forge holds the clone (the forge knows which runs are live); it logs one line per lock removed.
  • [ ] A run whose checkout still fails on a lock is re-queued once with a fresh clone instead of failing the follow-up.
  • [ ] test/crew-interrupted.test.ts: a kept clone with a planted config.lock resumes cleanly and the lock is gone.

Evidence: run on #1132 (reason feedback, 11:35Z) summary; locks cleared by hand at 11:5xZ with find /data/crew -name ".lock" -path "/.git/*" -mmin +5 -delete.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs