Skip to content
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

Bug: flushSync on component having useLayoutEffect in some cases causes Maximum update depth exceeded #27613

Closed
mareolan opened this issue Oct 27, 2023 · 3 comments
Labels
Resolution: Stale Automatically closed due to inactivity Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug

Comments

@mareolan
Copy link

React version: 18.2.0

Steps To Reproduce

  1. Click button Click me in the code example.
  2. You can see in console that the component gets re-rendered about 50 times and then React stops it.

Link to code example: https://codesandbox.io/s/infallible-joana-ysrxxt?file=/src/App.js
screenshot-after-click-me

The current behavior

It fails with Maximum update depth exceeded message.

The expected behavior

It should stabilize after few (2-4) re-renders, it definitely should not fail.

What seems to be happenning:

  1. After clicking the button, code waits for 500ms and then a state update for complexState is scheduled (but not yet processed) on row marked as R2.
  2. flushSync is called with another state update (R3). Seems like this update is performed by applying it to the last committed state, i.e. ignoring the state update that is scheduled by R2.
  3. After the commit of R3, layout effect depending on the complexState is performed, leading to state update, but of different state hook - counter state.
  4. At this point, I would expect that the component simply re-renders with the new counter state and does not trigger the layout effect (effect depending on complexState). Alas, it seems to re-run the state-updater from R3 (again!), which then leads to triggerring the layout effect again and hence the loop.
  5. Just for completeness - the step 4 would conclude the flushSync part of the example, and the component would then probably re-render again ~2 times, now applying both R2+R3 updaters (because R2 seems to be still only scheduled, not processed) and then counter update in layout effect would follow.

What I think is wrong is the re-applying of R3 state-updater in step 4 after layout effect (I think this state update should be considered as already committed). I don't know the React codebase much so the issue might be something else, e.g. maybe the counter state update in the layout effect gets applied to wrong committed state (as if it started off from the state that was there before user clicked the button, and React tries to apply accumulated changes, i.e. R3 + counter update?).

Other notes:

  • If you comment out R2, or replace useLayoutEffect by useEffect, all works as expected (but that should not be considered as a fix because you need useLayoutEffect to force an effect before paint, and you need flushSync for the same outside of effect, e.g. in ResizeObserver callback, see Bug: State updates in ResizeObserver callbacks are applied after paint and cause visual glitches #24331 ).
  • The example is simplified to better showcase the issue. In reality we had several async operations which got resolved and then got processed within the same event loop spin (microtasks), i.e. React scheduled an update with several state updates, but one of those ops had intentionally flushSync (without knowing about the other async ops) and it lead to this failure.
@mareolan mareolan added the Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug label Oct 27, 2023
@Vijay-948
Copy link

can u assign me i can do this

Copy link

github-actions bot commented Apr 5, 2024

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

@github-actions github-actions bot added the Resolution: Stale Automatically closed due to inactivity label Apr 5, 2024
Copy link

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Apr 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Stale Automatically closed due to inactivity Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug
Projects
None yet
Development

No branches or pull requests

2 participants