Rotorsoft / act-root / 31922167305

100%

push

github

feat(act): make the correlate checkpoint durable (#1493)

* feat(act): make the correlate checkpoint durable and single-writer

The checkpoint — how far correlate has READ the event log — lived in
process memory. Every worker kept its own, so N workers scanned the same
range and issued the same subscribe UPSERTs, and a restart guessed a
resume point from the subscription watermark minus a 10k back-scan.

It now lives in its own single-row relation, taken with lease_correlated
and advanced with ack_correlated — the claim/ack shape. A second worker's
lease returns undefined and it skips the scan instead of repeating it.
The lease is released on every exit path including failure, since a
parked lease would stall correlation for every worker, not just the one
that failed.

Its own relation rather than a reserved subscription row: that design was
built and rejected on evidence — a subscription row is counted by
prioritize, reset, unblock, query_streams and blocked_streams, and broke
16 tests including a prioritize count that read 2 instead of 1.

Deriving it from RFC 1486's MAX(correlated) was also rejected and
measured: correlated records what was found, not what was read, so the
floor cannot advance past a run of reaction-less events, and the paged
scan then re-reads the same page forever.

RFC: rfcs/1484-correlate-checkpoint.md

Closes #1484

* refactor(act): route the correlate checkpoint through claim/ack

Replaces the dedicated lease_correlated / ack_correlated port methods
with two exported constants and a reserved lane. The checkpoint IS a
lease plus a watermark, which is what claim/ack already mean, so adding
methods for it was surface creep — and every third-party adapter would
have had to implement both.

  const [lease] = await store().claim(1, 0, by, millis, CORRELATE_LANE);
  await store().ack([{ ...lease, at: last_id }]);

An empty claim means another correlator holds it, so this worker skips.
Storage is unchanged: its own single-row relatio... (continued)

4125 of 4125 branches covered (100.0%)

Branch coverage included in aggregate %.

52 of 52 new or added lines in 6 files covered. (100.0%)

8903 of 8903 relevant lines covered (100.0%)

586.53 hits per line