[Bugfix] Passive effects triggered by synchronous renders in a multi-root app #17347
+44
−2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The bug ------- In a multi-root app, certain passive effects (`useEffect`) are never fired. See facebook#17066. The underlying problem ---------------------- The implicit contract of `flushPassiveEffects` is that, right after calling it, there should be no pending passive effects. In the normal case, in concurrent mode, this is true. But the current implementation fails to account for the case where a passive effect schedules synchronous work, which in turn schedules additional passive effects. This led to `rootWithPendingPassiveEffects` being overwritten in the commit phase, because an assignment that assumed it was replacing null was actually replacing a reference to another root, which has the consequence of dropping passive effects on that root. The fix ------- The fix I've chosen here is, at the beginning of the commit phase, keep flushing passive effects in a loop until there are no more. This doesn't not change the "public" implementation of `flushPassiveEffects`, though it arguably should work this way, too. I say "public" because it's only used by implementation layers on top of React which we control: mainly, the legacy version of `act` that does not use the mock Scheduler build. So there's probably still a bug in that `act` implementation. I will address `act` in a follow-up. The ideal solution is to replace the legacy `act` with one implemented directly in the renderer, using a special testing-only build of React DOM. Since that requires a breaking change, we'll need an interim solution. We could make the "public" `act` recursively flush effects in a loop, as I've done for the commit phase. However, I think a better solution is to stop automatically flushing the synchronous update queue at the end of `flushPassiveEffects`, and instead require the caller to explicitly call `flushSyncUpdateQueue` (or the equivalent) if needed. This follows the same pattern we use internally in the work loop, which is designed to avoid factoring hazards like the one that resulted in this bug.
Details of bundled changes.Comparing: 2c6ea0b...c386a55 react-reconciler
react-dom
react-art
react-test-renderer
react-native-renderer
ReactDOM: size: 0.0%, gzip: 🔺+0.1% Size changes (stable) |
Details of bundled changes.Comparing: 2c6ea0b...c386a55 react-test-renderer
react-native-renderer
react-dom
react-art
react-reconciler
ReactDOM: size: 0.0%, gzip: 0.0% Size changes (experimental) |
gaearon
approved these changes
Nov 12, 2019
|
Do we know when this regressed? |
|
Not sure, I'll have to check. I'm going to cut a minor regardless, so I'll do that first. If enough people complain we can consider cutting some patches, too. |
|
Can we close #17066 now? Can you verify its repro works now? |
|
Verified with https://codesandbox.io/s/react-typescript-2thgm |
Closed
This was referenced Nov 23, 2019
This was referenced Sep 24, 2024
This was referenced Sep 25, 2024
This was referenced Sep 28, 2024
This was referenced Sep 29, 2024
This was referenced Oct 4, 2024
This was referenced Oct 5, 2024
This was referenced Oct 12, 2024
This was referenced Oct 25, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The bug
In a multi-root app, certain passive effects (
useEffect) are never fired. See #17066.The underlying problem
The implicit contract of
flushPassiveEffectsis that, right after calling it, there should be no pending passive effects. In the normal case, in concurrent mode, this is true. But the current implementation fails to account for the case where a passive effect schedules synchronous work, which in turn schedules additional passive effects.This led to
rootWithPendingPassiveEffectsbeing overwritten in the commit phase, because an assignment that assumed it was replacing null was actually replacing a reference to another root, which has the consequence of dropping passive effects on that root.The fix
The fix I've chosen here is, at the beginning of the commit phase, keep flushing passive effects in a loop until there are no more.
This doesn't not change the "public" implementation of
flushPassiveEffects, though it arguably should work this way, too. I say "public" because it's only used by implementation layers on top of React which we control: mainly, the legacy version ofactthat does not use the mock Scheduler build. So there's probably still a bug in thatactimplementation.I will address
actin a follow-up. The ideal solution is to replace the legacyactwith one implemented directly in the renderer, using a special testing-only build of React DOM. Since that requires a breaking change, we'll need an interim solution. We could make the "public"actrecursively flush effects in a loop, as I've done for the commit phase. However, I think a better solution is to stop automatically flushing the synchronous update queue at the end of
flushPassiveEffects, and instead require the caller to explicitly callflushSyncUpdateQueue(or the equivalent) if needed. This follows the same pattern we use internally in the work loop, which is designed to avoid factoring hazards like the one that resulted in this bug.