Update error recovery test to match new semantics

Author: acdlite

packages/react-reconciler/src/__tests__/ReactIncrementalErrorHandling-test.internal.js

@@ -243,11 +243,20 @@ describe('ReactIncrementalErrorHandling', () => {
     // This update is in a separate batch
     ReactNoop.render(<App isBroken={false} />, onCommit);
 
-    expect(Scheduler).toFlushAndYield([
+    expect(Scheduler).toFlushAndYieldThrough([
       // The first render fails. But because there's a lower priority pending
       // update, it doesn't throw.
       'error',
-      // Now we retry at the lower priority. This time it succeeds.
+    ]);
+
+    // React will try to recover by rendering all the pending updates in a
+    // single batch, synchronously. This time it succeeds.
+    //
+    // This tells Scheduler to render a single unit of work. Because the render
+    // to recover from the error is synchronous, this should be enough to
+    // finish the rest of the work.
+    Scheduler.unstable_flushNumberOfYields(1);
+    expect(Scheduler).toHaveYielded([
       'success',
       // Nothing commits until the second update completes.
       'commit',
@@ -296,10 +305,6 @@ describe('ReactIncrementalErrorHandling', () => {
     expect(ReactNoop.getChildren()).toEqual([]);
   });
 
-  // TODO: This is currently unobservable, but will be once we lift renderRoot
-  // and commitRoot into the renderer.
-  // it("does not retry synchronously if there's an update between complete and commit");
-
   it('calls componentDidCatch multiple times for multiple errors', () => {
     let id = 0;
     class BadMount extends React.Component {