Retention's page, after the review found the checkpoint launderable - #36
Merged
arpanghoshal merged 1 commit intoSep 14, 2026
Merged
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
kernel then found seven defects in it, and two of them are things this page asserts. **The checkpoint.** The page said a forged checkpoint is narrowed by the anchor. It was not: supersession was decided from the union of what the provider returned and what the store's own `anchors` table held, so one INSERT beside the forged checkpoint row bought it, and the hash in that row never had to be a hash. Supersession now comes from the provider alone, and the anchor's `(seq, hash)` must be the pair the checkpoint claims. The paragraph says that, including the half that is still true: anyone who can write receipts can write both rows. **The receipts.** A refused prune and a successful one left byte identical records, and `--older-than` was not among them, so the record of a refusal was worth nothing. The prune now leaves two, a request and its outcome, and the page has a short section saying so. The "verified by" line moves to the tests that actually bind. `T547b` passed throughout the laundering hole, because it writes the checkpoint row and no anchors row beside it; `T550` and `T559` are the ones that fail when supersession is decided locally. `CLAIMS.md`'s line numbers follow the CLI's new lines, and the readiness block is re-measured, not incremented: 6,210 against a checkout with the extras CI installs. Signed-off-by: arpan <contact@arpanghoshal.com>
arpanghoshal
force-pushed
the
v0.11/3a-retention-review
branch
from
September 14, 2026 17:59
3f53ea0 to
e704dd0
Compare
arpanghoshal
changed the base branch from
v0.11/3-retention
to
v0.11/5-enforcement-coverage
September 14, 2026 17:59
This was referenced Sep 14, 2026
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
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.
Pairs with ctrlrun#205, and stacks on #34, which is still open.
#34 described retention as it was written. An independent review of the kernel then found seven defects in it, and two of them are things that page asserts.
The checkpoint. The page said a forged checkpoint is narrowed by the anchor. It was not. Supersession was decided from the union of what the provider returned and what the store's own
anchorstable held, so one INSERT beside the forged checkpoint row bought it, and the hash in that row was never read. The paragraph now says what is true after the fix, including the half that was always true: anyone who can write receipts can write both rows, and what narrows that is the provider, which is outside the store.The receipts. A refused prune and a successful one left byte-identical records, and
--older-thanwas in neither. The prune now leaves two, a request and its outcome, and the page has a short section saying so.The "verified by" line moves to the tests that actually bind.
T547bpassed throughout the laundering hole, because it writes the checkpoint row and noanchorsrow beside it.Also here:
CLAIMS.md's line numbers follow the CLI's new lines, byscripts/repoint-claims.py; the readiness block is re-measured rather than incremented, 6,192 to 6,210, against a checkout carrying the extras CI installs and not the local one withpsycopg.🤖 Generated with Claude Code