Stale main.lock on anarbib/anarbib after HTTP 504 #2707

AnarBib commented 2026年06月01日 17:39:46 +02:00

Comment

Hi, there's a stale refs/heads/main.lock on the repo anarbib/anarbib after an HTTP 504 during a push today. Every push since fails with cannot lock ref 'refs/heads/main': Unable to create '.../anarbib.git/./refs/heads/main.lock': File exists. Objects transfer fine — only the ref update is blocked. Could you remove the stale lock? Thanks!

### Comment Hi, there's a stale refs/heads/main.lock on the repo anarbib/anarbib after an HTTP 504 during a push today. Every push since fails with cannot lock ref 'refs/heads/main': Unable to create '.../anarbib.git/./refs/heads/main.lock': File exists. Objects transfer fine — only the ref update is blocked. Could you remove the stale lock? Thanks!

AnarBib commented 2026年06月02日 00:22:01 +02:00

Update — repo AnarBib/anarbib, branch main
Follow-up on the stuck push. The original symptom (cannot lock ref 'refs/heads/main': File exists) no longer appears, so the orphaned lock seems to have been cleared — thanks if someone did that. However, pushes to main still don't complete: the objects transfer in full, then the push dies on an HTTP 504 at the finalize stage, and the server-side ref is never updated. The web UI still shows e55e0882e8 as the main HEAD (~7h old) while several newer commits are ready locally and won't land.
Client output:

Writing objects: 100% (56/56), 68.53 KiB | 7.61 MiB/s, done.
Total 56 (delta 43), reused 17 (delta 12), pack-reused 0
error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly

The timeout lands exactly at the post-receive / ref-update step, so this may be the same ongoing 500/504 server-load condition tracked in #2596 and in #2710 rather than a lock issue per se. Could an admin please (a) check whether a stale refs/heads/main.lock is still present server-side for this repo, and (b) confirm whether this is the known 504 situation? Since a 504 at finalize is what created the original lock, I'm holding off on retrying to avoid leaving another stale lock behind.
No rush — and thanks for the volunteer time. Happy to provide timestamps or anything else useful.

Update — repo AnarBib/anarbib, branch main Follow-up on the stuck push. The original symptom (cannot lock ref 'refs/heads/main': File exists) no longer appears, so the orphaned lock seems to have been cleared — thanks if someone did that. However, pushes to main still don't complete: the objects transfer in full, then the push dies on an HTTP 504 at the finalize stage, and the server-side ref is never updated. The web UI still shows e55e0882e8 as the main HEAD (~7h old) while several newer commits are ready locally and won't land. Client output: Writing objects: 100% (56/56), 68.53 KiB | 7.61 MiB/s, done. Total 56 (delta 43), reused 17 (delta 12), pack-reused 0 error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 send-pack: unexpected disconnect while reading sideband packet fatal: the remote end hung up unexpectedly The timeout lands exactly at the post-receive / ref-update step, so this may be the same ongoing 500/504 server-load condition tracked in #2596 and in #2710 rather than a lock issue per se. Could an admin please (a) check whether a stale refs/heads/main.lock is still present server-side for this repo, and (b) confirm whether this is the known 504 situation? Since a 504 at finalize is what created the original lock, I'm holding off on retrying to avoid leaving another stale lock behind. No rush — and thanks for the volunteer time. Happy to provide timestamps or anything else useful.

Gusted commented 2026年06月03日 02:19:14 +02:00

Fixed!

Fixed!