Revision column fails db-assert check - #4742
Closed
Romanx wants to merge 2 commits into
Closed
Conversation
jeremydmiller
added a commit
that referenced
this pull request
Jul 30, 2026
…5091) (#5092) * fix(#5091): fence the allocation history on allocated, not reserved, sequence The #4953/#5057 allocation fence was built from the sequence's RESERVED ceiling (mt_events_sequence.last_value), and Postgres reports last_value = 1 for a sequence nothing has drawn from yet. No poll could ever report a value at or below a stuck mark of 0, so findAllocationFence(0) always returned null: a leading gap — the mark pinned at 0 under a hole at the very start of the sequence — could never be fenced, and any permanently idle open transaction held it forever. That is the shape reported in #5090 ("holding before the sequence gap above 0"), where the quiescent-session exclusion was inert on 9.21.0. The statistics reading now also carries is_called, which distinguishes "1 has been handed out" from "1 is the next value to hand out", giving the highest ALLOCATED sequence number — 0 for a pristine sequence. The fence compares against that instead, which makes mark 0 fenceable without weakening the proof: everything above the allocated high was handed out strictly after the poll that observed it. The reserved ceiling still bounds how far a proven-dead skip may advance (StuckGapObservation.ReservedCeiling is unchanged), and per-tenant partitioned stores report no allocation reading at all, so they keep today's conservative no-fence behaviour. Also documents that a process starting more than one daemon-hosting IHost over its lifetime should prefer Events.UseAdvisoryLockTransaction = false, since a session-scoped leadership lock holds no open transaction that gap detection has to treat as a possible in-flight append. Tests cover the dead leading gap skipping past an idle advisory-lock session, a live reserver of the leading gap still holding the mark, and a detector that never saw the pristine sequence still holding conservatively. The first two are verified RED before the fix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Adopt JasperFx 2.36.3 and Weasel 9.20.2 (the #5090 chain) JasperFx 2.36.3 (#592/#593): ProjectionCoordinatorBase.StartAsync cancels AND drains any existing leadership loop instead of disposing the old CancellationTokenSource without cancelling it, so a bare ResumeAsync can no longer orphan a live loop that outlives StopAsync. Weasel 9.20.2 (weasel#396/#397): AdvisoryLock can no longer strand a handle acquired after DisposeAsync drained — the actual cause of the permanently 'idle in transaction' advisory-lock session in #5090. Weasel 9.20.2 also carries weasel#399/#400, found while making this bump: 9.18.0's computed-column delta detection made TableColumn.MatchesForDelta compare through the non-virtual Equals(TableColumn), bypassing subclass overrides of Equals(object). That is the seam RevisionColumn uses to tolerate an existing bigint mt_version (#4614/#4742), so every Weasel from 9.18.0 through 9.20.1 fails Bug_4614's assert-check test with an empty change set. 9.20.2 is the first version this repo can move to. Verified on the published packages: CoreTests 494, DaemonTests 260, EventSourcingTests 1478 — all green on net10.0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A test showing that the revision changes for bigint -> int skipping fails assert check on database.
This mirrors the checking being done in weasel as part of the db-assert command here.