Race condition when mutate is called multiple times in short succession with the same key

[derindutz]

Bug report

First off, thank you for your awesome work on this library 😊 I really enjoy using it and it's tremendously helpful.

Description / Observed Behavior

Calling mutate multiple times with the same key within a very short amount of time leads to a race condition. When I pass a callback function to mutate, if I update the value on call #1 of mutate, call #2 of mutate doesn't get the updated value.

This leads to weird unexpected bugs since it's not clear that the library will behave this way.

It seems like the bug is here: https://github.com/vercel/swr/blob/master/src/use-swr.ts#L131. If mutate is called multiple times in short succession, cache.get(key) will not be up to date.

Expected Behavior

I expect no race condition. When I update the value on call #1 of mutate, I expect the value to be updated on call #2 of mutate.

Repro Steps / Code Example

https://codesandbox.io/s/swr-mutate-race-condition-gnrs3

Additional Context

SWR version: 0.2.3
Add any other context about the problem here.

[kweiberth]

I think I'm experiencing something very similar to this. I'm building an optimistic UI, and if there are two quick edits made, the two local invocations of mutate(key, updateFn, false) don't each update the local cache; instead, only the first one updates it.

Any updates on a fix? Is it indeed due to cache.get(key) not getting updated.

PS, I'd like to echo @derindutz sentiment that this an awesome library it's been a pleasure to work with 🙏

[ranisalt]

Can confirm I'm having the same issue, using mutate returned from a call to useSWR, where the second call to mutate overrides the first if the second fires before the first finishes.

[blujedis]

Confirmed, so I'm not crazy....ya'll have me debugging like a mad man, this does seem like an issue with the key.

In my case an auth strategy that I am using seems to exacerbate the issue. This is because it calls server on render of component verifying roles before rendering the inner or content component.

Initially that it was the culprit but after inspection and some debugging it is in fact SWR it appears. If I disable SWR and just use a simple fetch there are no issues with timing or race conditions.

That all said just love this lib!!!

[shuding]

Hi @ranisalt I'd love to know if #735 fixes the issue you had.

[ranisalt]

@shuding I can't test it, I haven't had this issue anymore even before the merge.

[shuding]

@ranisalt No worries! Let me know if you see it again. 👍 Also thanks for reporting!