React.createContext with SSR leads to concurrency problems in environments with co-routines

First some context: i am using react SSR with meteor. Meteor uses node-fibers (co-routines, see https://github.com/laverdet/node-fibers), which enables async code to run synchronously without async/await or generators. So i think that React.renderToString could be interrupted by other code and this leads to the problem, but i am totally unsure.

Given the following code:

const MyContext = React.createContext();

const AppContent = () => (
    <MyContext.Consumer>
    {props => <SomeComponent {...props} />}
    </MyContext.Consumer>
)
const App = props => (
    <MyContext.Provider value={props}>
        <AppContent />
    </MyContext.Provider>
)

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

If <App /> gets rendered with different properties roughly at the same time, e.g.:

execution 1: <App foo="execution1" />

execution 2: <App foo="execution2" />

then SomeComponent might render twice with the same props (either twice execution1 or execution2

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn’t have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:

See above

What is the expected behavior?

Context consumer should only respect the current tree and pick up the value from the parent provider even in environments with fibers (co-routines)

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

16.5.2

[gaearon]

Yeah we don’t really write code with the assumption that every render can be interrupted. We’ve started work on a new SSR that would support that (although through our own mechanism — Suspense) but it’s going to be many months before it ships.

[aweary]

This comment also describes this problem/limitation:

The comment in ReactContext is specifically talking about cases where there are concurrent renderers (like using ReactDOM and ReactART at the same time), not actual concurrent execution environments.

React supports standard-compliant JavaScript environments, so using an environment with non-compliant concurrency primitives is going to cause problems.

I see you opened an issue on the Meteor repo. I think that’s the right place to report this, and hopefully the Meteor team can look into this for you.

Thanks!