`isPaused` stays `true` when resuming mutations from the cache

[RaphaelGimenez]

Describe the bug

Resuming a mutation from the cache does not set isPaused to true.

I suspect that it could come from the this.#retryer?.continue() not being set yet ->
https://github.com/TanStack/query/blob/main/packages/query-core/src/mutation.ts#L156

Your minimal, reproducible example

https://stackblitz.com/github/RaphaelGimenez/tanstackquery-ispaused-issue?file=README.md

Steps to reproduce

The example is running a json server and timeout all !GET request.

1. Open Stackblitz project, start script is set to preview
2. Go to Stackblitz port 4173
3. Toggle online by clicking the following button and delete post
   
4. Mutation is paused
   
5. Refresh the preview -> mutation is resumed but isPaused = true
   
6. Toggle offline / online -> mutation is correctly unpaused
   

Expected behavior

Resumed mutations from the persister should correctly set isPaused to false.

How often does this bug happen?

Every time

Screenshots or Videos

Screencast.From.2025-04-11.17-18-41.webm

Platform

• OS: Fedora
• Browser: Firefox, Chromium

Tanstack Query adapter

react-query

TanStack Query version

5.72.2

TypeScript version

No response

Additional context

No response

[HanhNguyenHong1802]

I observed the demo changes, and I saw after refreshing the app, resumePausedMutations() will run later. IMO, the isPaused state isn't cleared immediately on refresh because you are using persister, which is designed to retain the application's state across reloads. The resumePausedMutations() function is the mechanism to handle these paused mutations after the persisted state is loaded. If you want a different behavior, you need to modify how you use persistence.

[TkDodo]

sorry, I need a “better” example. Can you try trimming things down to the bare essentials please to make the issue appear?

I’m running into issues while debugging because when I follow the steps to reproduction, the mutation definitely does continue for me. It starts to error and I get weird popups from Stackblitz saying: This project requires a connection to your localhost.

Really, there’s no need to work with actual requests in an issue reproduction. Just do Promise.resolve() or Promise.reject() with some mock data and a bunch of timeouts to make it take a while and it should be much easier. But as it stands, I can’t debug this. Thanks.

I suspect that it could come from the this.#retryer?.continue() not being set yet

continuing on the retryer is only necessary when a mutation has been “paused” in the same session. When you restore it with a persister plugin, it’s on purpose that we call .execute()on the mutation to initiate the retryer.

[RaphaelGimenez]

@HanhNguyenHong1802
I'm resuming the mutations only once the persister loaded the cache:

<PersistQueryClientProvider
      client={queryClient}
      persistOptions={{
        persister,
      }}
      onSuccess={() => {
        queryClient.resumePausedMutations().then(() => {
          queryClient.invalidateQueries();
        });
      }}
    >

If you open the devtools and go to the mutaitons on refresh you can see that the mutation is shown as paused when it's actually running. I don't think this should be the case. A running mutation should not be in the paused state.

@TkDodo

sorry, I need a “better” example. Can you try trimming things down to the bare essentials please to make the issue appear?

My bad, I tried trimming it up, delete and getAll are now using Promises. Same stackblitz.
The preview script does not seem to work on chrome while it's working in firefox. My bad for not checking I fixed the stackblitz url to use default dev script.

continuing on the retryer is only necessary when a mutation has been “paused” in the same session. When you restore it with a persister plugin, it’s on purpose that we call .execute()on the mutation to initiate the retryer.

Yes this is what I understood. But the issue I see here is that since we directly call .execute we do not dispatch the continue action, which seems to be the part setting isPaused: false -> https://github.com/TanStack/query/blob/main/packages/query-core/src/mutation.ts#L289
Thus, when resuming a paused mutation from the persister, while it's correctly running the mutation, state.isPaused stays true.

---

I may be misunderstanding the logic here, but if I resume a paused mutation after the persisted state is loaded, its isPaused state should be false since the mutation is currently running.

As I understand it a running mutation should not be in the paused state, which appears to be the case here.

[TkDodo]

we do not dispatch the continue action

I think you are right with that. What needs to happen imo is that we additionally dispatch the continue even when isRestoring is set:

query/packages/query-core/src/mutation.ts

Lines 191 to 192 in c2861c4

	if (!restored) {
	this.#dispatch({ type: 'pending', variables, isPaused })

ideally, we would also extract it from here:

query/packages/query-core/src/mutation.ts

Lines 178 to 180 in c2861c4

	onContinue: () => {
	this.#dispatch({ type: 'continue' })
	},

to an onContinue function so that we make sure we always call the same things.

So this kinda becomes:

if(isRestored) {
  onContinue()
} else { ... }

Where onContinue would be:

const onContinue = () => {
  this.#dispatch({ type: 'continue' })
}

and we would also pass that to createRetryer.

If you’re up for it, please file a PR with that fix, but we’d also need a test case that fails on main and works with the fix. Thanks 🙏

[RaphaelGimenez]

Ok, I'll try to work on a PR :)