Repository navigation
Conversation
…lbacks When mutate() is called inside an onSuccess handler, this.#mutateOptions is overwritten before the subsequent onSettled call in #notify(). This causes onSettled to fire with the next mutation's callbacks but the current mutation's data and variables. Fix by snapshotting mutateOptions at the top of #notify() before any callbacks execute, so all three callbacks (onSuccess/onError/onSettled) see the same consistent options for the mutation that settled. Fixes TanStack#11451
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to No actionable merge-blocking issue is identified; the change is ready for normal checks. Pre-merge checks |
|
Fixes #11451
Problem
When
mutate()is called inside anonSuccesshandler,this.#mutateOptionsis overwritten in place (via line 221) beforeonSettledfires in#notify(). This causesonSettledto fire with the next mutation's callbacks paired with the current mutation's data and variables.Fix
Snapshot
this.#mutateOptionsinto a local variable at the top of#notify(), before any callback fires. All three callbacks (onSuccess/onError/onSettled) then read from the snapshot and see the correct options for the mutation that actually settled.This is the standard snapshot-before-dispatch pattern. Added a regression test in
mutationObserver.test.tsxthat fails before the fix and passes after.Summary by CodeRabbit
onSettledcallback runs once with the correct data and variables.