Rotorsoft / act-root / 33276871839

100%

push

github

fix(act): don't quarantine a stream while the database is failing (ACT-1592) (#1593)

* fix(act): refund claims a store failure spent, not the handler's retry budget

`claim` persists `retry = retry + 1` before any handler runs, and only a
confirmed write-back resets it. A cycle that throws on `fetch`, `block` or
`ack` therefore walked the counter up with no attempt behind it — four
transient `SQLITE_BUSY` rounds blocked the stream and prescribed a bigger
`leaseMillis` for a handler that never failed.

The drain now keeps a per-lane ledger of claims charged to the store. Every
claim is charged provisionally; a cycle that finalizes converts its claim into
a handler attempt, a cycle that throws leaves it charged, and the next claim
discounts what is still charged out of the `retry` the block decisions read.
The discounted lease travels through the claim-time budget check, the
dispatcher's block decision, and the counter a due-marked ack writes back, so
a refund becomes durable the moment the store confirms anything for the
stream. Handler failures still block after exactly `maxRetries` attempts, and
a lease genuinely lost every round still blocks at claim time.

Closes #1592

* fix(act): stand the claim-time block down while the store is failing

Replaces the per-stream ledger from the previous commit with the check the
ticket suggested: don't quarantine a stream while the store is failing.

`claim` writes the retry count up before any handler runs, and only a pass
that reaches its ack writes it back down, so a pass that dies on a store call
leaves a count no handler earned. A few of those look exactly like a lease
lost every round, which is what the claim-time block exists to catch, so a
healthy stream was quarantined over a transient database lock and told to
raise leaseMillis.

The circuit breaker already counts store failures since the last completed
pass, so the block reads that instead of keeping its own tally. Nothing is
lost by waiting: a genuin... (continued)

4295 of 4295 branches covered (100.0%)

Branch coverage included in aggregate %.

4 of 4 new or added lines in 2 files covered. (100.0%)

9275 of 9275 relevant lines covered (100.0%)

1177.45 hits per line