Repository navigation
fix(core): keep nodes a catch-up replay deletes and restores - #288
Closed
marcus-pousette wants to merge 3 commits into
Closed
marcus-pousette wants to merge 3 commits into
marcus-pousette wants to merge 3 commits into
Conversation
A catch-up after late ops replays the suffix from the frontier and patched only the nodes left in the coalesced replay changes. A delete and a later restore of the same node cancel out there, such as a peer's payload the delete didn't know about. The node was skipped although its stored row, which already reflects the old suffix, was still deleted with an older payload. It stayed that way until a later catch-up touched it, and neither onMaterialized nor changedSince reported it. Catch-up now patches every node a replayed op touched, plus their ancestors. The patch already reports a delete or restore against the stored row, so the restore is reported too.
marcus-pousette
marked this pull request as ready for review
November 2, 2026 13:59
The core unit test repeated the conformance scenario, which covers the same catch-up through the SQLite and Postgres backends and fails on main. The scenario also drops two ops it doesn't need: A's own delete is in the replayed range, so it already forces the full replay.
Collaborator
Author
|
Closing in favor of #286, which includes this PR's conformance scenario and a broader version of the catch-up fix: it repairs every node the replayed ops touch, which also covers rows that change with nothing reported, such as a delete that leaves its node visible. |
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.
A late batch from a peer could leave a node deleted with an older payload, while a fresh replica of the same ops has it restored with the newer one. It happens when the replayed ops delete the node and then restore it, such as a delete followed by a peer's payload the delete didn't know about. The node stayed wrong until a later catch-up touched it.
catch_up_materialized_staterewrote only the nodes left in the coalesced replay changes, where that delete and restore cancel out, although the stored row was still deleted. Catch-up now rewrites every node a replayed op touched, plus their ancestors.onMaterializedandchangedSincemissed the restore for the same reason. A new conformance scenario checks the node and both reports; it fails without the fix.