Context leaks to later renders when render stream destroyed early

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

Bug.

What is the current behavior?

If a stream created with .renderToNodeStream() is destroyed before the render completes, memory can be retained unnecessarily by Contexts which were active at the time.

It’s not a memory leak per se as memory use is not unbounded. There’s a limit on number of threads in use and context slots are reused, so memory use can’t increase endlessly.

Would only make a noticeable impact on an application which:

• renders using .renderToNodeStream() or .renderToStaticMarkup()
• stores large objects in Context (e.g. large data sets from fetch requests)
• experiences a spike in traffic which then recedes
• destroys a lot of streams prematurely (or has errors thrown in rendering which causes streams to be destroyed)

In the above case, when the spike hits, many threads are created for concurrent renderers. Each thread writes data into a slot of the Contexts it uses. When the threads are destroyed before the renders complete, the Context slots are not cleared, and so left filled with data which is no longer useful, but cannot be freed by GC.

When the spike recedes, this memory continues to be retained.

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:

I’ll submit a PR with failing test case and fix shorty.

What is the expected behavior?

When stream is destroyed, it should clean up its resources.

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

Issue introduced in 961eb65b4ba5de6bbfb6b8a075a924c284541177 which is in 16.7.0.

[gaearon]

Thanks @eliseumds for explaining your case, I added a regression test for it.

[overlookmotel]

Issue also affects .renderToString() if an error is thrown during the render, leading it being prematurely destroyed, leaving some contexts open.

Many would say that you should terminate the Node process on an unexpected error, but I imagine a lot of people catch it and send status 500 to the client.