Fix context providers in SSR when handling multiple requests

[frandiox]

Closes #23089

@sebmarkbage @gaearon Thanks for the pointers. This seems to fix the issue but I'm not very well versed in the fizz code. Please have a look to see if this makes sense.

Summary

Context providers are broken in SSR when handling multiple requests. See #23089 for more information.

How did you test this change?

Failing test submitted by @zythum in #23129 passes with this change. I've also tested a local issue we had in Hydrogen and it seems to be fixed.

[frandiox]

CI failed in Download artifacts for base revision 👀

[eps1lon]

CI failed in Download artifacts for base revision 👀

I'd rebase and then push an empty commit to see if this was just flaky CI or a reproducable issue.

[gaearon]

Can you cherry-pick the failing test commit and add it to the PR please?

[sebmarkbage]

This looks like the right fix. We just need the previously failing test pulled in so we don't regress.

To spell it out what's going on here, when we pop all the way to the root we need to push (update current value) all the contexts of the "next" stack. We miss one because it was only in the branches when we didn't quite reach the root.

[sebmarkbage]

Another test that should also be able to surface this same issue is to have two context without a shared provider but in the same request. Bonus points if you add a previously failing test for that too.

<div>
  <ContextA.Provider value={...}>
    <SuspendHere />
  </ContextA.Provider>
  <ContextB.Provider value={...}>
    ...
  </ContextB.Provider>
</div>

[gaearon]

I picked the failing test from #23129. Not sure why it's not showing @zythum's avatar but I left the original author on the commit as is.

[sizebot]

Comparing: e28a0db...ed36f94

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	=	129.59 kB	129.59 kB	=	41.55 kB	41.55 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js	=	134.77 kB	134.77 kB	=	43.10 kB	43.10 kB
facebook-www/ReactDOM-prod.classic.js	=	428.19 kB	428.19 kB	=	78.60 kB	78.60 kB
facebook-www/ReactDOM-prod.modern.js	=	418.18 kB	418.18 kB	=	77.17 kB	77.17 kB
facebook-www/ReactDOMForked-prod.classic.js	=	428.19 kB	428.19 kB	=	78.60 kB	78.60 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against ed36f94

[gaearon]

Another test that should also be able to surface this same issue is to have two context without a shared provider but in the same request

I tried it and it didn't fail with old code:

  // @gate experimental
  fit('should be able to pop context after suspending', async () => {
    class DelayClient {
      get() {
        if (this.resolved) return this.resolved;
        if (this.pending) return this.pending;
        return (this.pending = new Promise(resolve => {
          setTimeout(() => {
            delete this.pending;
            this.resolved = 'OK';
            resolve();
          }, 500);
        }));
      }
    }

    const DelayContext = React.createContext(undefined);
    const Component = () => {
      const client = React.useContext(DelayContext);
      if (!client) {
        return 'context not found.';
      }
      const result = client.get();
      if (typeof result === 'string') {
        return result;
      }
      throw result;
    };

    const OtherContext = React.createContext(undefined);
    const OtherComponent = () => {
      let res = React.useContext(OtherContext);
      if (res !== 'foo') {
        throw Error('no')
      }
      return res
    }

    const client = new DelayClient();
    const {writable, output, completed} = getTestWritable();
    ReactDOMFizzServer.renderToPipeableStream(
      <>
        <DelayContext.Provider value={client}>
          <Suspense fallback="loading">
            <Component />
          </Suspense>
        </DelayContext.Provider>
        <OtherContext.Provider value="foo">
          <OtherComponent />
        </OtherContext.Provider>
      </>
    ).pipe(writable);

    jest.runAllTimers();

    expect(output.error).toBe(undefined);
    expect(output.result).toContain('loading');
    expect(output.result).toContain('foo');

    await completed;

    expect(output.error).toBe(undefined);
    expect(output.result).not.toContain('context never found');
    expect(output.result).toContain('foo');
    expect(output.result).toContain('OK');
  })

What's missing?

[sebmarkbage]

@gaearon The first time it renders the inner Suspense boundary, it'll synchronously pop back out to the root and try to render its sibling. Try making the sibling also suspend.

You want the first sibling to render its "task" separately from the rest of the tree so that it leaves it hanging. This happens after it retries. So the error can only be observed after it has retried once. If the second one retries on the same ping, it'll probably be observed then.

[gaearon]

ok that worked. doesn't need to be different context, just separate providers.