inspector/clients
Repository files (latest commit first)
Filename Latest commit message Latest commit date
cliffhall 0cb59cf3fd fix(auth): stop heartbeating a lock that is no longer ours
Found on a re-read of the round-4 liveness work, not by review.

The heartbeat refreshed the lock directory's mtime unconditionally. After
a steal — possible when this process looked dead, or across hosts where
the pid check cannot apply — the directory belongs to someone else, and
touching it keeps *their* lock looking alive. If they then die, the stale
timestamp nobody is maintaining is being maintained by us, and a third
writer can never break in: a stale lock turned unbreakable, which is the
permanent outage the stealing exists to avoid.

The heartbeat now re-reads the owner stamp and clears itself when the
token no longer matches, so it only ever refreshes a lock we still hold.
The release path already checked the token; this closes the same hole on
the other side.

Tested by stamping a different owner onto a held lock and aging it: the
mtime stays old across several heartbeat intervals, and release leaves the
thief's lock intact.

Signed-off-by: cliffhall <cliff@futurescale.com>
2026-08-22 13:50:40 -04:00
..
cli chore(deps): bump nanoid to 3.3.18 to clear the high-severity advisory 2026-08-18 23:12:10 -04:00
launcher chore(deps): bump nanoid to 3.3.18 to clear the high-severity advisory 2026-08-18 23:12:10 -04:00
tui chore(deps): bump nanoid to 3.3.18 to clear the high-severity advisory 2026-08-18 23:12:10 -04:00
web fix(auth): stop heartbeating a lock that is no longer ours 2026-08-22 13:50:40 -04:00