You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
React 18. set state in finally throws "act" warning, though test is passing #1051
consthandleSavedCardPayment=()=>{constpaymentInfo={amount: formDataRef.current.amount,
userId,accountId: formDataRef.current.selectedCardAccountId,};dispatch(makePayment(paymentInfo)).then(handlePaymentSuccess).catch(noop)// already caught by thunk.finally(()=>{formDataRef.current=null;setSubmitting(false);});};
What you did:
NOTE: This error only shows up after updating to react 18 and testing library to 13.1.1, this was not an issue in earlier version.
setSubmitting toggles the button disability. When the promise is complete, it turns the re-enables the button. so the test is doing a waitFor button to be re-enabled.
the promise looks more like this
dispatch(makePayment(paymentInfo)) returns a promise, with a catch inside.
so the whole promise chain looks like this
promisedFunction().then(() => do something).catch(error => show error). then(() => componentLevel).catch(do nothing here).finally(reset state)
What happened:
the "act" error is thrown, even though i've added a waitFor and that is passing to prove that that statement has already been rendered.
I have observed the same behavior as @JoeyAtSS. After update to the latest React 18 and the latest RTL, we had to change following across whole application, otherwise error from above is shown:
We also observed #1057. Unfortunately, I haven't observed pattern in which it happens.
Reacted by Dave, rajithaw, Omid Mogasemi, Matthew Maloney and Dimitri Steinel
I am having a similar problem after updating to react 18.2.0 and @testing-library/react 13.3.0. Some of my calls to dispatch store actions need to be wrapped in await act(async () => {...} ). I thought that @testing-library/react took care of the act wrapping for us.
Reacted by Christopher Brenner, Victor Glindås, Szymon Nowak, Guilherme Galabarof , Matt Nelson, Miloš Lajtman, Amnon Sadeh, samir-jorge-araujo, Alex, Ivan Kaliada and 1 more
You can see this error when you run tests and check the output in the console. In our case it's triggered by a component that uses react-query with dynamic import.
We're getting these warnings/errors in other places as well (e.g. we had 2 getByText(...).click() calls right after each other and after updating to React 18, I had to wrap each in a separate act call), but I wasn't able to create a minimal example for these.
Reacted by Guilherme Galabarof , Matt Nelson, Amnon Sadeh and Saksham Bhatt
I'm running into the same problem upgrading my App to React 18, and RTL to 13.3.0.
In my case, I've even got a test which triggers an act warning for every letter pressed from await user.type() triggering an onChange handler, which just calls a setter from a useState hook.
Even if I add await waitFor(() => expect(myInput).toHaveValue(finalValue) it still throws the warnings (amongst hundreds of other act warnings in my other tests).
Reacted by Guilherme Galabarof , Michael Morelock, Matt Nelson, Olesia Shpykovskaia and Greg Hogan
Based on my tests, it looks likecleanup isn't being called at the end of every test as it used to. For me, if I manually unmount the component or call the cleanup function, the act errors go away.
Edit:
Note that calling cleanup in an afterEach will not work. You will have to actually call it at the bottom of the test. Something like this
test('should do something', () => {
render(<Component />);
// test stuff
cleanup();
});
Reacted by Guilherme Galabarof , Tobias Rundbom, Mike Grafton, Jonathan Avila, Kevin Kirsche, Antoine, Katsiaryna Pustakhod, Victory Ogbiyoyo, Elizabeth Pinero, Iskenderov Viacheslav and 1 more
It was already mentioned by others, but making sure that we only have one version of @testing-library/dom library helped us significantly reduce number of these warnings.
If you use yarn, you can run yarn why @testing-library/dom to see how many versions of this library you have and why. If you have more than one, it's probably best to uninstall all libraries that depend on it and reinstall them.
@intercaetera It's not runnable. Even after fixing the lockfile (npm ci failed), npm test I got a Validation Error. Repros need to be minimal and easily reproducible.
The repro from @szimek worked i.e. I could reproduce the bug with their repro. It also had problems though since it didn't have a lockfile. NPM couldn't even install it anymore. Only yarn succeeded. @szimek I could fix the missing-act warning with #1137 but the test is still failing which seems correct. The image is already rendered so the waitFor is not actually waiting for the data to render.
The 3rd repro from @robin-drexler finally worked (though still missing a lockfile). However, it's a clear example of a missing act. The warning got fixed by wrapping the state update in act:
In the future, please make sure repros are minimal and runnable indefinitely in the futre (e.g. they have a lockfile ensuring the same install, they have a Node.js version.
The repro from @szimek looks like a duplicate to #1125 so I'll close this issue once we land #1137
I'm getting more act warnings now with @testing-library@14.0.0.
Tested with await waitFor, and still throwing act warnings with userEvent that triggers a state change.
Activity
zanlib0 commentedon Apr 19, 2022
I encountered something similar while using Formik, I suspect this is related. Here is a repo which reproduces this issue:
This only happens on the new version of RTL and React 18.
clothoo commentedon Apr 28, 2022
I'm using react-hook-form and experience the same act warning. Using either
waitFororwaitForElementToBeRemoveddoesn't remove the warning.The only thing that worked is to wrap act with sleep.
credit to https://bufferings.hatenablog.com/entry/2021/11/18/015809
chore: upgrade version
chore: upgrade version
chore: upgrade version (#14)
hlmnd commentedon May 3, 2022
eps1lon commentedon May 21, 2022
It doesn't look like this bug report has enough info for one of us to reproduce it.
Please provide a CodeSandbox (https://react.new), or a link to a repository on GitHub.
Here are some tips for providing a minimal example: https://stackoverflow.com/help/mcve
zanlib0 commentedon May 26, 2022
@eps1lon Is my example in this comment not sufficient to demonstrate the issue?
bedrich-schindler commentedon Jun 8, 2022
I have observed the same behavior as @JoeyAtSS. After update to the latest React 18 and the latest RTL, we had to change following across whole application, otherwise error from above is shown:
We also observed #1057. Unfortunately, I haven't observed pattern in which it happens.
guilhermegalabarof commentedon Jun 24, 2022
Hey guys, i made some tests because I am having the same problem:
This is what I got.
This way it works fine:
But if I change to userEvent, I get the act() warning all over again.
bobsilverberg commentedon Jun 30, 2022
I am having a similar problem after updating to
react 18.2.0and@testing-library/react 13.3.0. Some of my calls to dispatch store actions need to be wrapped inawait act(async () => {...} ). I thought that @testing-library/react took care of theactwrapping for us.szimek commentedon Jul 4, 2022
@eps1lon I replicated our issue here: https://codesandbox.io/s/rtl-react-18-act-issue-forked-l0bcj2?file=/src/__tests__/App.test.js.
You can see this error when you run tests and check the output in the console. In our case it's triggered by a component that uses
react-querywith dynamic import.We're getting these warnings/errors in other places as well (e.g. we had 2
getByText(...).click()calls right after each other and after updating to React 18, I had to wrap each in a separateactcall), but I wasn't able to create a minimal example for these.thepuzzlemaster commentedon Jul 7, 2022
I'm running into the same problem upgrading my App to React 18, and RTL to 13.3.0.
In my case, I've even got a test which triggers an
actwarning for every letter pressed fromawait user.type()triggering anonChangehandler, which just calls a setter from a useState hook.Even if I add
await waitFor(() => expect(myInput).toHaveValue(finalValue)it still throws the warnings (amongst hundreds of other act warnings in my other tests).Aerophite commentedon Jul 13, 2022
Based on my tests, it looks like
cleanupisn't being called at the end of every test as it used to. For me, if I manually unmount the component or call thecleanupfunction, theacterrors go away.Edit:
Note that calling
cleanupin anafterEachwill not work. You will have to actually call it at the bottom of the test. Something like this13 remaining items
Revert "Update React and friend to latest version"
szymonnowak-st commentedon Dec 14, 2022
It was already mentioned by others, but making sure that we only have one version of
@testing-library/domlibrary helped us significantly reduce number of these warnings.If you use yarn, you can run
yarn why @testing-library/domto see how many versions of this library you have and why. If you have more than one, it's probably best to uninstall all libraries that depend on it and reinstall them.eps1lon commentedon Feb 16, 2023
@intercaetera It's not runnable. Even after fixing the lockfile (
npm cifailed),npm testI got a Validation Error. Repros need to be minimal and easily reproducible.The repro from @szimek worked i.e. I could reproduce the bug with their repro. It also had problems though since it didn't have a lockfile. NPM couldn't even install it anymore. Only yarn succeeded.
@szimek I could fix the missing-act warning with #1137 but the test is still failing which seems correct. The image is already rendered so the
waitForis not actually waiting for the data to render.The 3rd repro from @robin-drexler finally worked (though still missing a lockfile). However, it's a clear example of a missing
act. The warning got fixed by wrapping the state update inact:In the future, please make sure repros are minimal and runnable indefinitely in the futre (e.g. they have a lockfile ensuring the same install, they have a Node.js version.
The repro from @szimek looks like a duplicate to #1125 so I'll close this issue once we land #1137
eps1lon commentedon Feb 16, 2023
Fixed in #1137
Released in
@testing-library@14.0.0annidai commentedon Feb 17, 2023
I'm getting more
actwarnings now with@testing-library@14.0.0.Tested with
await waitFor, and still throwingactwarnings with userEvent that triggers a state change.Tested version:
"jest": "29.4.3",
"@testing-library/jest-dom": "5.16.5",
"@testing-library/react": "14.0.0",
"@testing-library/user-event": "14.4.3",
zigang93 commentedon Feb 20, 2023
@testing-library@14.0.0still have sameactwarningsmellai commentedon Feb 20, 2023
+1
zigang93 commentedon Feb 20, 2023
@eps1lon here is what I found out..
29.4.3have act warning.."jest": "^29.4.3""jest-environment-jsdom": "^29.4.3"but
29.3.1is working perfectly"jest": "^29.3.1""jest-environment-jsdom": "^29.3.1"@smellai give it a try, hope can help to solve it
eps1lon commentedon Feb 20, 2023
For people still having issues, please file a new one and include a minimal, cloneable reproduction. Just a list of dependencies is not sufficient.