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

[Bugfix] Prevent infinite update loop caused by a synchronous update in a passive effect #22277

Merged
merged 2 commits into from
Sep 9, 2021

Conversation

acdlite
Copy link
Collaborator

@acdlite acdlite commented Sep 9, 2021

The bug

In 18, passive effects are flushed synchronously if they are the result of a synchronous update. We have a guard for infinite update loops that occur in the layout phase, but it doesn't currently work for synchronous updates from a passive effect, which means if this scenario happens, the main thread will lock up and crash the tab.

The reason this probably hasn't come up yet is because synchronous updates inside the passive effect phase are relatively rare: you either have to imperatively dispatch a discrete event, like el.focus, or you have to call ReactDOM.flushSync, which triggers a warning. (In general, updates inside a passive effect are not encouraged.)

I discovered this because useSyncExternalStore does sometimes trigger updates inside the passive effect phase.

The fix

The way we detect a "nested update" is if there's synchronous work remaining at the end of the commit phase.

Currently this check happens before we synchronously flush the passive effects. I moved it to after the effects are fired, so that it detects whether synchronous work was scheduled in that phase.

In 18, passive effects are flushed synchronously if they are the
result of a synchronous update. We have a guard for infinite update
loops that occur in the layout phase, but it doesn't currently work for
synchronous updates from a passive effect.

The reason this probably hasn't come up yet is because synchronous
updates inside the passive effect phase are relatively rare: you either
have to imperatively dispatch a discrete event, like `el.focus`, or you
have to call `ReactDOM.flushSync`, which triggers a warning. (In
general, updates inside a passive effect are not encouraged.)

I discovered this because `useSyncExternalStore` does sometimes
trigger updates inside the passive effect phase.

This commit adds a failing test to prove the issue exists. I will fix
it in the next commit.
@facebook-github-bot facebook-github-bot added CLA Signed React Core Team Opened by a member of the React Core Team labels Sep 9, 2021
// checking if remainingLanes includes Sync work, instead of whether there's
// any work remaining at all (which would also include stuff like Suspense
// retries or transitions). It's been like this for a while, though, so fixing
// it probably isn't that urgent.
Copy link
Collaborator Author

@acdlite acdlite Sep 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated to fix, just noticed it while I was here and left a comment for later

@sizebot
Copy link

sizebot commented Sep 9, 2021

Comparing: 4ce89a5...720b041

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name +/- Base Current +/- gzip Base gzip Current gzip
oss-stable/react-dom/cjs/react-dom.production.min.js +0.01% 128.25 kB 128.27 kB = 40.92 kB 40.93 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js +0.01% 131.08 kB 131.09 kB = 41.85 kB 41.85 kB
facebook-www/ReactDOM-prod.classic.js = 407.05 kB 407.09 kB = 75.40 kB 75.40 kB
facebook-www/ReactDOM-prod.modern.js = 395.61 kB 395.65 kB +0.02% 73.68 kB 73.69 kB
facebook-www/ReactDOMForked-prod.classic.js = 407.05 kB 407.09 kB = 75.40 kB 75.40 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against 720b041

@acdlite acdlite force-pushed the infinite-passive-update-loop branch from 7b453b1 to 39bbe82 Compare September 9, 2021 01:10
@acdlite acdlite force-pushed the infinite-passive-update-loop branch from 39bbe82 to 686cc6b Compare September 9, 2021 01:15
The way we detect a "nested update" is if there's synchronous work
remaining at the end of the commit phase.

Currently this check happens before we synchronously flush the passive
effects. I moved it to after the effects are fired, so that it detects
whether synchronous work was scheduled in that phase.
@acdlite acdlite force-pushed the infinite-passive-update-loop branch from 686cc6b to 082f49f Compare September 9, 2021 01:21
@acdlite acdlite changed the title [Bugfix] Prevent infinite update loop inside caused by a synchronous update in a passive effect [Bugfix] Prevent infinite update loop caused by a synchronous update in a passive effect Sep 9, 2021
@acdlite acdlite merged commit 8f96c6b into facebook:main Sep 9, 2021
facebook-github-bot pushed a commit to facebook/react-native that referenced this pull request Sep 22, 2021
Summary:
This sync includes the following changes:
- **[f4ac680c7](facebook/react@f4ac680c7 )**: Fixed broken build script --unsafe-partial flag ([#22324](facebook/react#22324)) //<Brian Vaughn>//
- **[67222f044](facebook/react@67222f044 )**: [Experiment] Warn if callback ref returns a function ([#22313](facebook/react#22313)) //<Dan Abramov>//
- **[263cfa6ec](facebook/react@263cfa6ec )**: [Experimental] Add useInsertionEffect ([#21913](facebook/react#21913)) //<Ricky>//
- **[806aaa2e2](facebook/react@806aaa2e2 )**: [useSES shim] Import prefixed native API ([#22310](facebook/react#22310)) //<Andrew Clark>//
- **[fd5e01c2e](facebook/react@fd5e01c2e )**: [useSES/extra] Reuse old selection if possible ([#22307](facebook/react#22307)) //<Andrew Clark>//
- **[33226fada](facebook/react@33226fada )**: Check for store mutations before commit ([#22290](facebook/react#22290)) //<Andrew Clark>//
- **[86c7ca70a](facebook/react@86c7ca70a )**: Fix link ([#22296](facebook/react#22296)) //<Konstantin Popov>//
- **[0fd195f29](facebook/react@0fd195f29 )**: update error message to include useLayoutEffect or useEffect on bad e… ([#22279](facebook/react#22279)) //<salazarm>//
- **[8f96c6b2a](facebook/react@8f96c6b2a )**: [Bugfix] Prevent infinite update loop caused by a synchronous update in a passive effect ([#22277](facebook/react#22277)) //<Andrew Clark>//
- **[4ce89a58d](facebook/react@4ce89a58d )**: Test bad useEffect return value with noop-renderer ([#22258](facebook/react#22258)) //<Sebastian Silbermann>//
- **[a3fde2358](facebook/react@a3fde2358 )**: Detect subscriptions wrapped in startTransition ([#22271](facebook/react#22271)) //<salazarm>//

Changelog:
[General][Changed] - React Native sync for revisions 95d762e...e8feb11

jest_e2e[run_all_tests]

Reviewed By: rickhanlonii

Differential Revision: D30966369

fbshipit-source-id: 6c88e591005deb1fd93493628ef4695add49186c
zhengjitf pushed a commit to zhengjitf/react that referenced this pull request Apr 15, 2022
…in a passive effect (facebook#22277)

* Add test that triggers infinite update loop

In 18, passive effects are flushed synchronously if they are the
result of a synchronous update. We have a guard for infinite update
loops that occur in the layout phase, but it doesn't currently work for
synchronous updates from a passive effect.

The reason this probably hasn't come up yet is because synchronous
updates inside the passive effect phase are relatively rare: you either
have to imperatively dispatch a discrete event, like `el.focus`, or you
have to call `ReactDOM.flushSync`, which triggers a warning. (In
general, updates inside a passive effect are not encouraged.)

I discovered this because `useSyncExternalStore` does sometimes
trigger updates inside the passive effect phase.

This commit adds a failing test to prove the issue exists. I will fix
it in the next commit.

* Fix failing test added in previous commit

The way we detect a "nested update" is if there's synchronous work
remaining at the end of the commit phase.

Currently this check happens before we synchronously flush the passive
effects. I moved it to after the effects are fired, so that it detects
whether synchronous work was scheduled in that phase.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed React Core Team Opened by a member of the React Core Team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants