-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
useSWR calling fetcher sometimes too often in unit test #1874
Comments
I tried downgrading swr to 0.5.6 during investigation, but the flaky behavior happened there too. |
Hi, This is indeed hard to trigger, I tried but couldn't. A few observations:
Good that you are trying to produce a test that should make things easier to test in case there's an actual bug. However, if you don't see this issue in production/development, then I'd point a finger at the testing environment. |
I maybe over-simplified the pseudo-code. I have some more array items in the key.
There are a lot more hooks.
It‘s too big, especially the rendered components. I‘m trying to compact it, but that takes a lot of time. I‘m hoping to rather find out more with console.logs in the swr code (happy for pointers).
The rendered data looks fine, so the issue is just unnecessary calls to the fetcher which is not possible to spot in production. So I‘m not sure if these unnecessary api calls happen in production too. It‘s an issue because I have no other way of unit testing that the api is called with the correct parameters. |
Ok, now I see an issue on production too, even though it's the opposite: the key of |
I debugged through the reproducible issue on production (where the fetcher is not called even though the key updated), and it looks like the body of the Could this be a react bug in |
Ah, and the SWR version? I am not sure I see the problem here, please do help me understand.
I think we need @shuding on this one. However, I think we need a to start to think of a test case, or whether or not this is expected behavior, though I think not. |
swr version is 1.2.2.
exactly. i could reproduce it both in a prod build and a dev build. in the dev build, i added console.logs to swr code, and saw the same behavior as in the browser debugger: i also logged the dependency array of |
btw. my pseudocode is something like this (next.js app):
this is vastly simplified though. note that executing |
ok, the |
I created a reproducing example and a react bug ticket for the second issue: facebook/react#24042 |
Bug report
Description / Observed Behavior
I'm using
useSWR
in a component that I test with react-testing-library. In most cases the unit test passes, but sometimes it fails when checking how often thefetcher
of theuseSWR
hook has been called and with which parameters. The rendered dom looks fine though. Note that I change the key of theuseSWR
hook to represent filtering in my application. For unit tests I use the recommended<SWRConfig value={{ dedupingInterval: 0, provider: () => new Map() }}>
to avoid flakiness. I don't userefreshInterval
.The unit test renders a component without a filter, then enters a search term into a filter input which updates the
useSWR
key, and after that, the search term is deleted again.From the logs of one of the flaky failed tests I see this order of execution:
Expected Behavior
The
fetcher
function should not be called unnecessarily, and especially it should behave deterministically.Repro Steps / Code Example
I do not yet have a reproduction repo yet, I'm still trying to make the error appear consistently in my own application's unit tests, but that's the issue with flakiness.
I'd be happy though to get hints on where I could add console.logs to find out the root cause. Or ideas on why swr could behave that way and call the fetcher with
"searchText":"my search text"
two times in a row (sometimes).Additional Context
SWR version: 1.2.2
Note that the issue mostly happens on slower CI machines, so the theory is that the root cause is a race condition in the internal swr state. Maybe something like
useSWR
is rendered, puts in a request into its queue, thenuseSWR
is rerendered and even though the deduping interval is 0, it does not yet see that the first request is enqueued because of some scheduling state issue, and enqueues another request. Could that be the case?The text was updated successfully, but these errors were encountered: