fix: handle stale sync tx data - #12850
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR improves db-sync robustness when client-generated outliner tx data becomes stale relative to the server DB even though t-before still matches, by sanitizing tx batches more aggressively and enriching transaction metadata with request context for diagnostics.
Changes:
- Add request context (
graph-id,client-revision,username) into transact metadata for WS and HTTP tx/batch handlers. - Treat move-like operations that target already-missing entities as sanitizable no-ops (drop missing-entity ops), and sanitize delete operations (drop redundant writes + retract current descendants).
- Add/extend worker handler tests to cover request-context tx-meta and stale tx sanitization scenarios.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| deps/db-sync/src/logseq/db_sync/worker/handler/ws.cljs | Captures graph/user context on WS and passes it through to tx/batch handling. |
| deps/db-sync/src/logseq/db_sync/worker/handler/sync.cljs | Adds request-context support and expands tx sanitization options for stale move/delete outliner ops. |
| deps/db-sync/src/logseq/db_sync/tx_sanitize.cljs | Adds helpers to drop ops targeting missing/retracted entities before transact, supporting stale/no-op batches and cleaner deletes. |
| deps/db-sync/test/logseq/db_sync/worker_handler_ws_test.cljs | Adds WS test asserting request context is present in tx-meta. |
| deps/db-sync/test/logseq/db_sync/worker_handler_sync_test.cljs | Adds sync handler tests for request-context meta and stale-move/delete sanitization behavior. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
tiensonqin
force-pushed
the
logseq/fix-stale-sync-tx
branch
from
July 3, 2026 18:35
a8217fa to
ba040ff
Compare
tiensonqin
force-pushed
the
logseq/fix-stale-sync-tx
branch
from
July 6, 2026 10:22
08d9c31 to
2e3647c
Compare
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.
Summary
Fix db-sync stale transaction handling and stabilize incremental checksum updates without falling back to recomputing checksums during normal operation.
:batch-tx-report?metadata and use that metadata for checksum/local-tx decisions instead of mutable@conn :batch-tx?state.Root Cause
The server stale-tx issue came from client-materialized outliner tx data that could pass the coarse
t-beforerevision check while still containing entity references that were no longer valid in the server DB. Delete batches could also leave descendant/property-value blocks in an invalid parent state, causing legitimate servertx/rejectfailures.The incremental checksum mismatch was a separate client/server shared implementation bug: checksum and local pending-tx logic inferred whether a tx report was an inner batch report from mutable connection state. Under concurrent batch/sync activity, a non-batch tx report could be processed while
@conn :batch-tx?was still true, so real graph changes were skipped by the incremental checksum path even though the data had changed.Validation
rtk bb dev:test -v frontend.worker.db-sync-test/local-checksum-updates-non-batch-report-with-stale-batch-flag-test -v frontend.worker.db-sync-test/local-checksum-updates-ldb-non-batch-report-with-stale-batch-flag-test -v frontend.worker.db-sync-test/batch-transact-tags-inner-tx-reports-testrtk bb dev:test -v logseq.db-sync.worker-handler-sync-test/tx-batch-delete-blocks-ignores-redundant-updates-and-deletes-descendants-test -v logseq.db-sync.worker-handler-sync-test/tx-batch-stale-retract-block-includes-current-descendants-test -v logseq.db-sync.worker-handler-sync-test/tx-batch-stale-retract-page-includes-current-page-tree-test -v logseq.db-sync.worker-handler-sync-test/tx-batch-rejects-move-blocks-when-target-is-missing-test2af3643cb98c7388; notx/reject, checksum mismatch, or sync error log matches.rtk git diff --check