fix(db): compose optimistic updates from changes instead of whole-row snapshots - #1701
Open
marbemac wants to merge 1 commit into
Open
fix(db): compose optimistic updates from changes instead of whole-row snapshots#1701marbemac wants to merge 1 commit into
marbemac wants to merge 1 commit into
Conversation
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughOptimistic updates now merge only changed fields over the current row, preserving unrelated fields across concurrent transactions, sync commits, and rollbacks. Tests cover composition, defaults, synchronization, rollback isolation, and redundant event suppression. ChangesOptimistic composition
Estimated code review effort: 3 (Moderate) | ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
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.
🎯 Changes
Small fix to how the optimistic overlay composes rows.
Today an optimistic insert/update stores
mutation.modified— the whole row as it looked atmutate()time — intooptimisticUpserts. Sincemodifiedis built from the visible row (Object.assign({}, visibleRow, payload)inmutations.ts), whichever transaction sorts last dictates every field, including ones it never touched.The clearest symptom: rolling back one of several in-flight transactions doesn't actually remove its change.
It doesn't change when committed sync gets applied. Sync still stays queued while a transaction is
persisting, exactly as today. That's the half of #1630 that turned out to be unsound without temp/server key mapping, and it's not needed for any of this.So this is only the projection half — same base as before, just composed per-field instead of replaced wholesale.
Related to RFC #1625.
t3's snapshot was taken when
bwas alreadyb2, so once t2 is gone t3 puts it right back. I don't think there's a reading of that which is correct.The fix:
updatemutations now composemutation.changesover the value they were layered on, so a mutation only owns the fields it actually changed. Inserts keep usingmodified, since an insert'schangesdeliberately omit schema defaults (there's a comment inmutations.tssaying as much).✅ Checklist
pnpm test.🚀 Release Impact
Summary by CodeRabbit