Rehydrated mutations are being run multiple times, once in each tab

[PabloRomanH]

I'm encountering an issue when trying to implement dehydration of mutations.
We are dehydrating mutations using a default mutation function. The issue is that if the device goes offline and the mutation is saved, then any new tabs or windows that are opened rehydrate that mutation and try to run it themselves when the device goes back online. How can I avoid this?

We are using broadcastQueryClient to synchronize data between tabs, and persist data using persistWithIndexedDB.

[TkDodo]

Not sure I understand the requirements here. Usually, you store to disk because you want a new tab to pick up where you left ?

[PabloRomanH]

The point of persisting queries and mutations is that they will be available when I open the site after having closed all the tabs.

[TkDodo]

okay but this sounds like you want to have your cake and eat it, too ...

[PabloRomanH]

Why, though? This seems to me the most obvious way how persisting mutations should work.

If you're not persisting mutations and a mutation is attempted while offline, it will be only run once when coming back online, even if there are multiple tabs open. That behavior should not be different just because you are persisting mutations.

From my point of view, right now, persisting mutations is simply broken.

[TkDodo]

tabs don't know anything about each other. if you open the same app in two tabs, they will both read the data from storage, so they will both see a paused mutation that they should retry. Now maybe the broadcastQueryClient plugin would inform other tabs that one mutation has already been triggered, but since the replay happens at the same time, this would likely already have been too late.

I think it's just technically really hard to:

• store state in the same storage
• read it from different tabs at the same time
• still treat them as a shared resource where we'd need a semaphore / lock.

basically you're saying persisted mutation should only ever be read out from storage once? I guess you can try to implement that on the layer that reads from indexDB. So if you have one mutation stored in indexDB, and you try to read it out from two different tabs, it will only land in memory of one tab. If the other tab never sees it, it won't attempt to replay it.

[PabloRomanH]

Thanks for your help. It seems that right now browsers are not quite there yet in terms of letting a website truly behave as an app. It seems shared service workers could be a solution but they haven't been implemented in mobile chrome yet.

Reading about what people have done to solve the problem of syncing state between tabs it seems a common solution is doing what you suggest and choosing one tab as the "leader", so we'll probably have to do that.