[Bugfix] Passive effects triggered by synchronous renders in a multi-…

…root app (#17347)

* Regression test: Effects dropped across roots

See #17066

* [Bugfix] Passive effects loop

The bug
-------

In a multi-root app, certain passive effects (`useEffect`) are never
fired. See #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.

packages/react-dom/src/__tests__/ReactDOMFiberAsync-test.internal.js

@@ -9,7 +9,7 @@
 
 'use strict';
 
-const React = require('react');
+let React;
 let ReactFeatureFlags = require('shared/ReactFeatureFlags');
 
 let ReactDOM;
@@ -26,6 +26,7 @@ describe('ReactDOMFiberAsync', () => {
   beforeEach(() => {
     jest.resetModules();
     container = document.createElement('div');
+    React = require('react');
     ReactDOM = require('react-dom');
     Scheduler = require('scheduler');
 
@@ -587,6 +588,39 @@ describe('ReactDOMFiberAsync', () => {
     );
   });
 
+  it('regression test: does not drop passive effects across roots (#17066)', () => {
+    const {useState, useEffect} = React;
+
+    function App({label}) {
+      const [step, setStep] = useState(0);
+      useEffect(
+        () => {
+          if (step < 3) {
+            setStep(step + 1);
+          }
+        },
+        [step],
+      );
+
+      // The component should keep re-rendering itself until `step` is 3.
+      return step === 3 ? 'Finished' : 'Unresolved';
+    }
+
+    const containerA = document.createElement('div');
+    const containerB = document.createElement('div');
+    const containerC = document.createElement('div');
+
+    ReactDOM.render(<App label="A" />, containerA);
+    ReactDOM.render(<App label="B" />, containerB);
+    ReactDOM.render(<App label="C" />, containerC);
+
+    Scheduler.unstable_flushAll();
+
+    expect(containerA.textContent).toEqual('Finished');
+    expect(containerB.textContent).toEqual('Finished');
+    expect(containerC.textContent).toEqual('Finished');
+  });
+
   describe('createBlockingRoot', () => {
     it.experimental('updates flush without yielding in the next event', () => {
       const root = ReactDOM.createBlockingRoot(container);

packages/react-reconciler/src/ReactFiberWorkLoop.js

@@ -1713,7 +1713,15 @@ function commitRoot(root) {
 }
 
 function commitRootImpl(root, renderPriorityLevel) {
-  flushPassiveEffects();
+  do {
+    // `flushPassiveEffects` will call `flushSyncUpdateQueue` at the end, which
+    // means `flushPassiveEffects` will sometimes result in additional
+    // passive effects. So we need to keep flushing in a loop until there are
+    // no more pending effects.
+    // TODO: Might be better if `flushPassiveEffects` did not automatically
+    // flush synchronous work at the end, to avoid factoring hazards like this.
+    flushPassiveEffects();
+  } while (rootWithPendingPassiveEffects !== null);
   flushRenderPhaseStrictModeWarningsInDEV();
 
   invariant(