You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit f974f81
Browse filesBrowse the repository at this point in the historyBrowse files
fix(defender): share the fingerprint module and separate lock errors from contention
Two issues cubic raised that I had not picked up, both in code added by this PR.
`depsFingerprint()` had been copy-pasted into four files, and the client's value
and the daemon's recorded value are compared to decide whether a daemon still
matches the tree on disk. Nothing kept the copies in step, so editing one would
have produced either a kill/respawn loop on every scan or a permanently stale
daemon: precisely the failures the check exists to prevent. It now lives in
scripts/deps-fingerprint.mjs, imported by both sides in each plugin. The state
file comment claiming the daemon reads the client's stamp was also stale, since
round three changed it to compute its own; corrected.
`acquireDepsLock()` returned null for both contention and genuine failure, and
the caller read every null as contention. A real error such as a permissions
problem therefore marked an install in flight, which suppresses daemon
replacement and leaves the old tree scanning indefinitely. It now reports the
two cases separately: contention scans with the current tree, an error skips the
event so the next hook retries.
Verified: the shared module is deterministic and the only remaining copy, a free
lock is taken, a live owner reports contention, and an unopenable lock path
reports an error rather than false contention. Both suites pass, 15 and 12.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
0 commit comments