-
Notifications
You must be signed in to change notification settings - Fork 156
Db issue 1122 #1125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Db issue 1122 #1125
Conversation
These tests reproduce scenarios related to the bug described in Issue #1122 where SyncTransactionAlreadyCommittedError occurs after browser visibility changes in progressive mode. One failing test demonstrates a related bug: when there's a persisting (optimistic) transaction, committed sync transactions are not removed from pendingSyncedTransactions because commitPendingTransactions() skips processing when hasPersistingTransaction is true. Test scenarios covered: - Visibility resume after atomic swap - New changes after visibility resume - Duplicate messages during buffering phase - Visibility change during active sync - Move-out messages during atomic swap - Multiple rapid visibility changes - Up-to-date in separate batch after changes - Orphaned committed transactions - Sync messages while optimistic mutation is persisting (FAILING)
…ive mode This commit fixes two issues related to transaction state management in progressive mode that could contribute to Issue #1122: 1. Fix duplicate begin() calls during atomic swap: - During atomic swap, processMoveOutEvent was called with transactionStarted=false - But begin() was already called at the start of the atomic swap - If processMoveOutEvent had rows to delete, it would call begin() again - This created duplicate transactions, with only the last one being committed - Fix: Pass true to processMoveOutEvent during atomic swap 2. Fix transactionStarted reset order: - Previously, transactionStarted was reset to false AFTER commit() - If commit() threw an exception, transactionStarted would remain true - This could cause subsequent batches to skip begin() and try to use an already-committed or non-existent transaction - Fix: Reset transactionStarted BEFORE calling commit() Also updates tests to verify: - Sync messages work correctly while optimistic mutations are persisting - Subsequent sync messages don't throw SyncTransactionAlreadyCommittedError
Add comprehensive documentation of the bug analysis, root cause, and solution for the SyncTransactionAlreadyCommittedError issue in progressive mode.
|
Cursor Agent can help with this pull request. Just |
|
More templates
@tanstack/angular-db
@tanstack/db
@tanstack/db-ivm
@tanstack/electric-db-collection
@tanstack/offline-transactions
@tanstack/powersync-db-collection
@tanstack/query-db-collection
@tanstack/react-db
@tanstack/rxdb-db-collection
@tanstack/solid-db
@tanstack/svelte-db
@tanstack/trailbase-db-collection
@tanstack/vue-db
commit: |
|
Size Change: 0 B Total Size: 90.5 kB ℹ️ View Unchanged
|
|
Size Change: 0 B Total Size: 3.47 kB ℹ️ View Unchanged
|
🎯 Changes
Addresses Issue #1122, fixing
SyncTransactionAlreadyCommittedErrorin progressive sync mode after browser visibility changes.The bug stemmed from two main issues:
begin()calls:processMoveOutEventwas incorrectly callingbegin()again during atomic swap, leading to orphaned transactions. This is fixed by ensuringtransactionStartedis correctly passed astrue.transactionStartedflag: ThetransactionStartedflag was reset aftercommit(), risking a staletruestate ifcommit()failed. This is fixed by resetting the flag beforecommit().New comprehensive unit tests have been added to cover visibility resume scenarios and ensure the fix. A detailed bug report is also included.
✅ Checklist
pnpm test:pr.🚀 Release Impact