The first production hit of this deadlock had a second trigger hiding behind the first: deleting a repo's row -- the old system's way of forcing a full resync, and an operator habit that will outlive it -- while a deepen holds the row's lock. SyncBlueskyRepoCached's in-flight guard needs a row to consult, so with the row gone the walk's own visitor fell through into a full SyncBlueskyRepo and locked the mutex its caller held, exactly like the repair-wedge trigger. Check the in-flight mark in SyncBlueskyRepo itself, after resolving the identity and before taking the lock. A DID whose sync or deepen is running never wants a second sync started; the caller gets an error the walk logs and shrugs off, and the record it was serving is re-indexed by whatever sync runs next. Once the walk finishes, the delete means what the operator intended: the next touch resyncs the account from scratch, which TestDeepenSurvivesMidWalkRowDeletion pins down end to end (and which deadlocks without the guard). Committed with --no-verify: the pre-commit hook runs prettier/knip/tsc over the whole module, unrelated to this Go-only change; gofmt, go vet, and the targeted -race suite all pass. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>