Rotorsoft / act-root / 33075268786

100%

push

github

fix(act): explain a failed correlation-lease handback instead of logging it raw (#1578)

* fix(act): explain a failed correlation-lease handback instead of logging it raw

The handback is best-effort — the lease carries its own expiry, so failing
costs at most lease_millis before a successor takes over. It also runs during
shutdown, where the store is at its most contended, so on a single-writer
store like SQLite a second connection holding the file makes it fail
routinely.

The bare "SQLITE_BUSY: database is locked" stack that produced at the end of
a clean Ctrl-C reads as a fatal shutdown fault. It now says what failed, that
the lease expires on its own, and what usually causes it.

Also corrects the act-sqlite README, which claimed writes "queue
automatically" — true on the store's own connection, false across two, where
the loser fails instantly because busy_timeout defaults to 0. Documents why
raising busy_timeout is not the fix: the busy wait blocks the Node event
loop, so the other connection's commit cannot run and the wait is guaranteed
to time out.

Closes #1577

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5eB6CMELZJfayCYpQta8N

* fix(act): warn rather than error on a failed lease handback

Operators wire alerting to error-level logs. A failure here loses nothing and
self-heals when the lease expires, so an error-level line means a clean
Ctrl-C pages someone every time — which is the complaint that opened #1577,
not just the wording.

Drops the Error wrapper with it: the stack points at the catch, not at
whatever holds the lock.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5eB6CMELZJfayCYpQta8N

---------

Co-authored-by: rotorsoft <rotorsoft@outlook.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

4302 of 4302 branches covered (100.0%)

Branch coverage included in aggregate %.

1 of 1 new or added line in 1 file covered. (100.0%)

9274 of 9274 relevant lines covered (100.0%)

1167.17 hits per line