resumePausedMutations and idempotence

[savetheclocktower]

Based on my experience and how the code seems to behave, I gather that this is what happens when you call queryClient.resumePausedMutations:

• The mutation cache finds all its mutations with a state of “paused.”
• It unpauses them.
• It resumes them, then bundles them all into a composite Promise that resolves when they're all done.

This is enormously useful. In my use case, it means that an arbitrary query can wait for any currently paused mutations to unpause themselves; when the user returns online from being offline, it allows me to ensure all paused mutations are committed before we ask for new data.

But suppose I have two such queries that don't coordinate. The first one to execute will correctly wait for all paused mutations to resume and finish before it proceeds. The second to execute — even if it's one millisecond later! — seems like it will call await queryClient.resumePausedMutations() and continue sooner than the first query; since none of those mutations are paused anymore, there will be nothing to await.

In my case, I worked around this by having each query call a wrapper function that keeps track of this. (It'll still call resumePausedMutations, just in case there are newly paused mutations, but then compose the returned promise with the first one.) But it feels like this would be useful to have in some form. I want something that says “wait for any in-flight mutations to finish” and works the same way whether I call it once or ten times in a row.

I suspect that I could throw this together by being really clever about how I use the methods on MutationCache. But if something like resumePausedMutations warrants its own shorthand, maybe this does, too?

[TkDodo]

I think resuming is something you should do globally, like, when network connection is regained, not on a query level. The query can wait until all mutations are done by checking useIsMutating.

[savetheclocktower]

I think resuming is something you should do globally, like, when network connection is regained, not on a query level. The query can wait until all mutations are done by checking useIsMutating.

Yeah, to be clear: we definitely resume globally when network condition is regained, but we defined a custom resumePausedMutations (which calls queryClient.resumePausedMutations and saves the promise) and also a function called awaitPausedMutations (which awaits that saved promise). A few crucial queries use the latter to wait for mutations to finish.

But it sounds like useIsMutating (combined with the enabled option of useQuery, I gather?) is a more elegant way of doing the same thing. Thanks!