# fix\(server\): retry the create after reclaiming a confirmed stale lock · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/commit/5dd4ca7ff38c4efdc7bf6fe7e9b9fd689c33d3fe)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

Requested revision: 5dd4ca7ff38c4efdc7bf6fe7e9b9fd689c33d3fe

Requested commit: 5dd4ca7ff38c4efdc7bf6fe7e9b9fd689c33d3fe

Commit: 5dd4ca7ff38c4efdc7bf6fe7e9b9fd689c33d3fe

Tree: 250a0af67b44ff9aa1b15943b49671d1e49544c9

Author: NoahLinckeScout

Committer: NoahLinckeScout

## Message

```
fix(server): retry the create after reclaiming a confirmed stale lock

Macroscope on the previous commit: reclaiming a dead lock returned
ServerLockUnavailableError even with no competing starter, so the first
restart after a crash failed instead of claiming the freed directory; and a
shutdown racing readHolder to remove the lock sent fs.utimes a NotFound that
failed the starter outright.

A confirmed-dead reclaim now retries the exclusive create on the next pass, so
a clean restart after a crash claims its directory in one call. The retry is
still bounded — MAX_RECLAIM_CYCLES — so a lock another starter keeps
recreating, or a permissions wall keeps failing to remove, surfaces as
ServerLockUnavailableError rather than spinning. Both refresh paths tolerate
NotFound between the read and the utimes, which closes the shutdown race; the
two paths shared a tail and now use one branch.

Verified: serverSingleton suite 14/14, typecheck exit 0.

```

## Parents

- [68697eb0006a622012d7735c7f71f90eea919224](https://git.cafe/pingdotgg/t3code/commit/68697eb0006a622012d7735c7f71f90eea919224?format=markdown)

[Source at this commit](https://git.cafe/pingdotgg/t3code/tree/5dd4ca7ff38c4efdc7bf6fe7e9b9fd689c33d3fe?format=markdown)