useMutation invokes the next mutation's onSettled with the previous result
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 72/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- react, typescript
Direzione di ricerca
Inizia in packages/query-core/src/mutationObserver.ts intorno a MutationObserver.#notify (righe 240-293) e riproduci gli scenari di mutazioni annidate dal CodeSandbox collegato. Verifica che la callback onSettled della seconda mutazione venga eseguita solo con il proprio risultato, errore e variabili, anche quando la seconda chiamata omette options e quando la sua promise rimane pending.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Describe the bug
When a per-call onSuccess or onError callback starts another mutation using the same useMutation instance, the second mutation's onSettled callback receives the first mutation's result and variables. It runs again with its own result when the second mutation finishes.
The reproduction logs only the callback registered for the second mutation:
[
{ "data": "result-1", "error": null, "variables": 1 },
{ "data": "result-2", "error": null, "variables": 2 }
]
Your minimal, reproducible example
https://yjdm6m.csb.app/ https://codesandbox.io/s/yjdm6m
Steps to reproduce
- Open the reproduction and click
1. Start second mutation in onSuccess. - Observe that the second mutation's callback receives both
result-1/ variables1andresult-2/ variables2. - Click
2. Start second mutation in onError. The second mutation's callback similarly receives the first mutation's error and variables before receiving its own successful result. - As a control, click
3. Sequential calls outside callbacks. This correctly logs only the second mutation's result once. - Repeat with StrictMode enabled using the link at the bottom. The behavior is the same.
Expected behavior
The second mutation's onSettled callback should run only after that mutation settles, with its own data, error, and variables:
[
{ "data": "result-2", "error": null, "variables": 2 }
]
This is not a request to invoke per-call callbacks for every consecutive mutation. The issue is that the latest mutation's callback receives a different mutation's result.
How often does this bug happen?
Every time
Screenshots or Videos
No response
Platform
- macOS 26.5
- Chromium 150.0.0.0, as reported by the browser's user agent
- React / React DOM 19.2.1
- Reproduces with StrictMode both enabled and disabled
Tanstack Query adapter
react-query
TanStack Query version
@tanstack/[email protected] and @tanstack/[email protected]
TypeScript version
No response
Additional context
In additional local checks, the second mutation was held pending using a manually resolved Promise. Its onSettled callback still received the first mutation's result before the second mutation finished.
Omitting the second call's optional options argument also produces an internal TypeError, even though the user callback does not throw:
mutation.mutate(1, {
onSuccess: () => {
mutation.mutate(2)
},
})
TypeError: Cannot read properties of undefined (reading 'onSettled')
In MutationObserver.#notify, this.#mutateOptions.onSettled is read after invoking onSuccess or onError. The nested mutate call replaces #mutateOptions, while the action's result and variables still belong to the first mutation.
The pending-Promise and omitted-options cases were checked separately locally; the shared sandbox contains the three button scenarios described above.
Codex assisted with preparing and verifying the reproduction.
- Lingua principale
- TypeScript
- Stelle
- 50.4k
- Fork
- 4.2k
- Merge medio
- 22h 57m
- PR unite (30g)
- 255
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di TanStack/query
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
TanStack/query#11358 · 2 commenti · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
TanStack/query#11106 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 58/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 74/100
TanStack/query#11639 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di TanStack/query
Issue simili
-
module-request
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
ports get and web print 'Port N already in use, trying next...' for every busy port they skipAperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
appandflow/stim#1604 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
lingdojo/kana-dojo#31060 · 1 commento · 5 reazioni ·
I maintainer di solito rispondono entro 1 giorno
-
SSH workspace restore rewrites relative symlinks into the deleted sync-back staging directoryAperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
paperclipai/paperclip#14173 ·
I maintainer di solito rispondono entro 1 giorno
-
needs-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno