fix(svelte-query): useMutationState array never shrank when mutations stopped matching filter - #11254
Conversation
… stopped matching filter Object.assign copies enumerable own properties but never sets Array.length. When nextResult was shorter than result (fewer mutations matched the filter), trailing stale entries were never removed — the array only ever grew. Fix: replace Object.assign with result.splice(0, result.length, ...nextResult). splice keeps the reactive $state array reference intact (required by Svelte 5 runes) while correctly adjusting length, adding, and removing elements. Adds a regression test: two pending mutations, both settle, assert the filtered result shrinks to []. Fixes TanStack#11152 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
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)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthrough
ChangesMutation state shrink fix
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This localized change corrects stale mutation-state entries and adds regression coverage; no actionable merge-blocking risk remains beyond normal checks and review. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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 |
Summary
useMutationState()in@tanstack/svelte-querynever removed entries from its returned array. Once a mutation stopped matchingfilters(settled, was garbage-collected, ormutationCache.clear()was called), the stale entry stayed in the array forever.Root cause
The cache-subscription callback updates the reactive
$statearray with:Object.assigncopies enumerable own properties — the numeric indices ofnextResult— but never adjustsArray.length. WhennextResultis shorter thanresult, the trailing stale entries are never touched andresult.lengthis never updated.This bug was introduced in the Svelte 5 runes rewrite (#9694) and has been present since.
Fix
splicekeeps the$statearray reference intact (required by Svelte 5 runes — reassigningresult = nextResultwould lose reactivity) while correctly adjustinglength, replacing all elements, and removing stale trailing entries.Test
Added regression test: two mutations started concurrently both match
filters: { status: 'pending' }. After both settle, the result array must shrink to[]. Previously this assertion failed — the array stayed["pending", "pending"]indefinitely.All 7 existing tests continue to pass.
Fixes #11152
Summary by CodeRabbit
Bug Fixes
Tests