Runtime APIs: MessageChannel

[phase]

The MessageChannel API is available on node but not CF Workers. This is causing an issue during the deployment of sites using React 19 + Astro + Workers, see facebook/react#31827 and withastro/astro#12824. The usage of this API may be a bug for this use case (meaning the solution there may be to stop using MessageChannel), but workerd may want to support it anyway.

I made a repository with steps to reproduce the crash mentioned in those issues here: https://github.com/phase/test-astro-react19-cf-workers

[jasnell]

Relabeling this as a feature request. The fact that we currently do not support MessageChannel is currently intentional as there aren't really any usable use cases for it in the runtime currently. It is something we can revisit but it likely won't be soon. To help with that, it would be helpful to have a better idea of how MessageChannel is being used in this particular case.

[IgorMinar]

First of all, thank you for a clear reproduction @phase! It helped me a lot understand what's going on.

Secondly, I agree with @jasnell that supporting MessageChannel in workerd is indeed non-trivial because it doesn't fit the rest of the runtime well. Browsers and node can create new JS contexts at will via iframes or node:vm APIs respectively and then you can use MessageChannel API to communicate between these JS contexts. But in workers the only way to create a new JS context today is to deploy a separate worker which has been an intentional design choice because of our serverless approach to computing.

However, looking at this issue more deeply, i think the root cause of the failures in Astro and React is not that we don't support MessageChannel API, but rather that the bundlers somehow erroneously picks up ReactServerStreamConfigBrowser (which uses MessageChannel to implement scheduleWork) rather than ReactServerStreamConfigEdge (which uses setTimeout) or even ReactServerStreamConfigNode (which uses setImmediate).

I think we should get to the bottom of how these modules are resolved and resolve them correctly to address the Astro/React issue.

[jasnell]

After discussing a bit internally, I think we will likely implement MessageChannel regardless but I think @IgorMinar is correct here... it would seem like choosing one of the other config providers would be ideal here. We support both setTimeout and setImmediate and it's not entirely clear exactly why the browser variation is even using MessageChannel in the first place.

[IgorMinar]

My guess is that they use MessageChannel because it's the fastest way to create and execute tasks in situations where you can't use microTasks because that would execute the work too early. They are essentially trying to recreate setImmediate's behavior in the browser.

[jasnell]

... They are essentially trying to recreate setImmediate's behavior in the browser.

setTimeout(fn, 0) would do the same and is the way setImmediate() is typically polyfilled in the browser, so it is a bit strange.

[IgorMinar]

setTimeout(fn, 0) is throttled to 4ms by browsers: https://developer.mozilla.org/en-US/docs/Web/API/Window/setTimeout#throttling_of_tracking_scripts

The workaround for when you need low latency tasks is to use MessageChannel API which is not throttled like this.

[IgorMinar]

Anyway, the point here is that due to some kind of build misconfiguration workerd is fed with js files intended specifically for browsers and not for servers which means that we might see additional issues due to this bundling issue and we should address that. I can have @dario-piotrowicz dig into this next week.

[Skye-31]

Anyway, the point here is that due to some kind of build misconfiguration workerd is fed with js files intended specifically for browsers and not for servers which means that we might see additional issues due to this bundling issue and we should address that. I can have @dario-piotrowicz dig into this next week.

Pretty sure this is why https://github.com/cloudflare/workers-sdk/blob/dc2ab3578956be656064cbfc7cc3e92bdae43092/packages/wrangler/src/deployment-bundle/bundle.ts#L66

[IgorMinar]

I'm not so sure @Skye-31. I initially thought the same, but then I noticed two things:

The react-dom/server export supports workerd condition with a higher priority than the browser condition: https://unpkg.com/browse/react-dom@19.0.0/package.json#L57

And @phase mentioned in withastro/astro#12824 (comment) that the following alias resolves the issue:

  vite: {
    resolve: {
      // Use react-dom/server.edge instead of react-dom/server.browser for React 19.
      // Without this, MessageChannel from node:worker_threads needs to be polyfilled.
      alias: import.meta.env.PROD && {
        "react-dom/server": "react-dom/server.edge",
      },
    },
  },

Given the workaround, my thinking is that this has nothing to do with Wrangler, and instead the app is bundled incorrectly with Vite in Astro. Possibly because the resolution conditions in the Astro Vite config are misconfigured?

At least that would explain why overriding the vite config in astro.config.mjs makes the problem go away.

[IgorMinar]

I debugged this and found bugs in the Astro adapter that is causing the original MessageChannel issue: withastro/astro#12824 (comment)