Manual writes should validate against the synced store, not the combined synced + optimistic store #708
Conversation
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
…andler This test reproduces issue #706 where calling writeDelete() inside an onDelete handler causes unexpected behavior. The Root Cause: When collection.delete() is called, it creates a transaction and calls commit() before calling recomputeOptimisticState(). Because commit() is async but starts executing immediately, the onDelete handler runs BEFORE the optimistic delete is applied to the collection state. Timeline: 1. collection.delete('1') is called 2. Transaction is created with autoCommit: true 3. commit() is called (async, but starts immediately) 4. Handler runs inside commit() - optimisticDeletes is empty! 5. commit() completes 6. recomputeOptimisticState() is finally called - too late Expected Behavior: - optimisticDeletes.has('1') should be TRUE when handler runs - writeDelete('1') should throw DeleteOperationItemNotFoundError Actual Behavior (BUG): - optimisticDeletes.has('1') is FALSE when handler runs - writeDelete('1') succeeds instead of throwing - This causes state inconsistencies and silent failures The test will fail until this timing issue is fixed. Related: packages/db/src/collection/mutations.ts lines 529-537 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
…teDelete This test reproduces issue #706 where calling writeDelete() inside an onDelete handler causes the deleted item to reappear. The Complete Root Cause: ======================== When collection.delete() is called with an onDelete handler that uses writeDelete(): 1. Transaction is created and commit() starts (mutations.ts:531) 2. Transaction NOT yet added to state.transactions (line 533 runs after) 3. onDelete handler runs while transaction.state = 'persisting' 4. Handler calls writeDelete('1') 5. writeDelete checks for persisting transactions in state.transactions 6. Finds NONE (transaction not added yet), commits synced delete immediately 7. Item removed from syncedData ✓ 8. Handler completes 9. wrappedOnDelete automatically calls refetch() (query.ts:681) 10. Refetch fetches data from server 11. Server still has item (transaction delete hasn't executed yet) 12. Refetch OVERWRITES syncedData with server data ✗ 13. Item reappears! The Two-Part Bug: ================ Part 1: Transaction added to state.transactions AFTER commit() starts - In mutations.ts:529-537, commit() is called on line 531 - Transaction added to state.transactions on line 533 (too late) - Handler runs before transaction is in the map - This allows writeDelete to commit immediately Part 2: Automatic refetch undoes the synced write - In query.ts:674-686, wrappedOnDelete automatically refetches - Unless handler returns { refetch: false } - Refetch restores server data, overwriting synced changes - This is the reason the item reappears Test Demonstrates: - writeDelete succeeds (no error) - Synced transaction committed immediately (persisting transactions: 0) - queryFn called twice (initial + refetch) - Final state: item still present (BUG!) Expected: Item should stay deleted after writeDelete Actual: Automatic refetch restores it 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Corrected understanding of the bug based on issue details:
- User returns { refetch: false } so automatic refetch is not the cause
- User also deletes on backend, so refetch would work anyway
The Real Bug:
=============
The issue is that errors thrown by writeDelete() inside onDelete handlers
are silently swallowed by .catch(() => undefined) in mutations.ts:531
When optimistic delete IS applied before handler runs:
1. collection.delete('1') creates optimistic delete
2. collection.has('1') returns false
3. onDelete handler runs
4. Handler calls writeDelete('1')
5. writeDelete validates: !collection.has('1') → throws DeleteOperationItemNotFoundError
6. Error propagates, commit() rejects
7. .catch(() => undefined) SILENTLY SWALLOWS error
8. User sees: execution stops, no error message, item flickers and reappears
The test demonstrates calling writeDelete in onDelete with refetch: false
(the exact pattern from the issue). The .catch(() => undefined) is the
root cause that prevents users from seeing errors.
Note: Due to timing (transaction not in state.transactions when handler runs),
this test hits the scenario where writeDelete succeeds. The bug manifests
when the optimistic delete IS applied, causing writeDelete to throw.
Related code: mutations.ts:531
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
…ned view The bug: When calling writeDelete() inside an onDelete handler, it would throw DeleteOperationItemNotFoundError because it checked the combined view (synced + optimistic) which already had the item optimistically deleted. The fix: Change manual-sync.ts to check only the synced store, not the combined view. Changes in packages/query-db-collection/src/manual-sync.ts: - Line 116: Changed from ctx.collection.has(op.key) to ctx.collection._state.syncedData.has(op.key) - Line 120: Same change for delete validation - Line 155: Changed from ctx.collection.get(op.key) to ctx.collection._state.syncedData.get(op.key) - Line 173: Same change for delete operation - Line 182: Changed ctx.collection.has(op.key) to ctx.collection._state.syncedData.has(op.key) for upsert Why this fixes the issue: - writeDelete operates on the synced store, not the optimistic state - Validation should match the store being modified - This allows write operations to work correctly even when items are optimistically modified - Now handlers can safely call writeDelete/writeUpdate regardless of optimistic state Test updated: - Renamed test to reflect it now verifies the fix works - Test passes: writeDelete succeeds, handler completes, item deleted successfully - No errors thrown, execution continues as expected Fixes #706 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: c3f3a51 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
More templates
@tanstack/angular-db
@tanstack/db
@tanstack/db-ivm
@tanstack/electric-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: |
- Removed console.log and debugging output from test - Removed lengthy comment explanations - Simplified test to be concise and focused - Added changeset describing the fix 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
|
Size Change: 0 B Total Size: 84.3 kB ℹ️ View Unchanged
|
|
Size Change: 0 B Total Size: 2.89 kB ℹ️ View Unchanged
|
|
Nope, misunderstood it, it's the manure sync methods, this looks good to me |
samwillis
approved these changes
Oct 23, 2025
KyleAMathews
deleted the
claude/reproduce-issue-011CUNK1MsVUpVKUz1B9vzPD
branch
Merged
|
🎉 This PR has been released! Thank you for your contribution! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Fixes #706
Previously we were validating calls to write* calls against the combined sync+optimistic view — which failed if you'd already made some types of optimistic changes. This PR fixes validation to only look at the synced store as that's where write* calls are going to.