High-water allocation fence: read is_called so mark 0 is fenceable (#5091)

[jeremydmiller]

Closes #5091. Third and last piece of the #5090 chain; the other two shipped upstream and are adopted here.

The fence could never fire at mark 0

#5057 added the allocation fence so a provably-quiescent idle in transaction session can be ruled out as a candidate reserver of a stale sequence gap instead of pinning the high water mark forever. findAllocationFence(mark) looks for a recorded poll where the sequence was at or below the stuck mark — but it compared against the reserved ceiling (mt_events_sequence.last_value), and Postgres reports last_value = 1 for a sequence nothing has drawn from yet. No poll can ever report a value at or below a mark of 0, so a leading gap — the mark pinned at 0 under a hole at the very start of the sequence — was never fenceable, and any permanently idle open transaction held it forever. That is the reporter's shape in #5090: Daemon high water detection is holding before the sequence gap above 0, with the #5057 exclusion inert on 9.21.0.

is_called distinguishes "1 has been handed out" from "1 is the next value to hand out", which yields the highest allocated sequence number — 0 for a pristine sequence. The fence now compares against that.

This does not weaken the proof: everything above the allocated high was handed out strictly after the poll that observed it, which is the same monotonicity argument #5057 relies on. Unchanged in both directions:

• StuckGapObservation.ReservedCeiling still bounds how far a proven-dead skip may advance, and still comes from last_value.
• Per-tenant partitioned stores have no store-global allocation reading (tenants draw from their own sequences), so AllocatedSequenceHigh is null there and they keep today's conservative no-fence behaviour.
• A detector that starts up over a gap that already exists still has no fence, and still holds.

Tests

DaemonTests/Bugs/Bug_5091_allocation_fence_at_mark_zero.cs:

• a_dead_leading_gap_skips_despite_an_idle_advisory_lock_session — the fix.
• a_live_reserver_of_the_leading_gap_still_holds_the_mark — fencing mark 0 must not become a licence to skip live appends.
• a_detector_that_never_saw_the_pristine_sequence_still_holds_conservatively — the documented degradation is intact.

The first two are verified RED before the fix (mark stuck at 0 in both); the third passes either way, as intended.

Dependencies — this is what actually fixes #5090

• JasperFx 2.36.3 (Skip().Take() ordering in compiled queries #592/mt_transform_patch_doc created in public schema #593): ProjectionCoordinatorBase.StartAsync cancels and drains any existing leadership loop rather than disposing the old CancellationTokenSource without cancelling it. A bare ResumeAsync used to orphan a live loop that outlived StopAsync, re-took leadership after ReleaseAllLocks, and won a lock handle after that lock had been disposed.
• Weasel 9.20.2 (weasel#396/Use the more efficient return mechanism for the generated upsert #397): AdvisoryLock can no longer strand a handle acquired after DisposeAsync drained — the actual cause of Stopped host can leak the HotCold coordinator's advisory-xact-lock session ("idle in transaction"), which 9.16.1 gap detection treats as an eternal in-flight append — stalling every later daemon in the same process #5090's permanently idle in transaction session on pg_try_advisory_xact_lock.

Weasel 9.20.2 also carries weasel#399/#400, a regression found while making this bump and worth flagging: 9.18.0's computed-column delta detection routed every column through TableColumn.MatchesForDelta, where a bare Equals(actual) binds to the protected non-virtual Equals(TableColumn) overload and bypasses subclass overrides of Equals(object). That override is exactly how RevisionColumn tolerates an existing bigint mt_version (#4614/#4742), so Bug_4614's assert-check test fails with an empty change set on every Weasel from 9.18.0 through 9.20.1. 9.20.2 is the first version this repo can move to.

Docs

Notes that a process starting more than one daemon-hosting IHost over its lifetime — the usual xUnit integration-suite shape — should prefer Events.UseAdvisoryLockTransaction = false, since a session-scoped leadership lock holds no open transaction for gap detection to treat as a possible in-flight append. markdownlint and cspell clean.

Verification

On the published packages, net10.0: CoreTests 494/494, DaemonTests 260/260, EventSourcingTests 1478/1478 (7 skipped).

🤖 Generated with Claude Code