`renderToString` disposes its root via `setTimeout`; graphs are retained across synchronous renders

[ryansolid]

Version: 2.0.0-rc.8 (@solidjs/web)

packages/web/src/server.ts ~1534:

let html = root(
  d => {
    setTimeout(d);
    return resolveSSRSync(escape(code()));
  },
  { id: renderId }
);

The root (and every memo/computation created under it) lives until the next macrotask. In any code path that renders more than once per task — benchmarks, batch pre-rendering, tests, Promise.all over many renderToString calls — nothing is released until the loop yields.

Measured

Rendering @yak/solid's base runtime (one memo per element) 1000 elements per call, tight loop, --expose-gc:

renders	heap growth
500	+121 MB
2500	+608 MB

≈243 KB retained per render; the same loop with a setImmediate yield between renders stays flat. React's renderToString is flat in the tight loop. The practical effect: a synchronous renderToString microbenchmark understated that runtime by 2–6× on larger workloads purely from GC pressure (ryansolid/yak-bench, see the method notes), and the published Solid-vs-React numbers in next-yak#644 were taken with exactly such a loop.

Even on a real server this holds each request's whole reactive graph one macrotask longer than necessary.

Why it's deferred (to confirm)

Presumably so that cleanups (head-tag registrations, httpStatus/httpHeader scope declarations, asset tracking) don't run before serializeFragmentAssets / renderShellHead / assembleDocument read their state — the streaming path documents "the head is committed right before the render's final dispose".

Proposed fix

Capture d and call it synchronously at the end of renderToString, after assembleDocument — same ordering guarantee, no macrotask hold. If something genuinely needs the dispose to happen after the caller receives the string, queueMicrotask bounds the retention to the current task instead of the next turn of the event loop.

Notes

• renderToStream has its own dispose plumbing (if (firstFlushed) dispose()); check whether the sync path can share it.
• A regression test: render N times in a loop, force GC, assert heap is bounded (or assert getOwner()-visible disposal via an onCleanup counter that must equal N before the loop returns).

[JohannesGezachew]

I looked into this, and the suggested fix (disposing the root before renderToString returns) conflicts with the scope-tied response primitives, so I held off on a PR.

With the setTimeout replaced by a synchronous dispose in a finally after assembleDocument, the server suite (854 passing on next) fails three tests:

• http-components.spec.tsx › httpStatus › declares status and statusText on the event's response during SSR: expected 200 to be 404
• http-components.spec.tsx › httpHeader › declares a header on the event's response during SSR: expected null to be 'no-store'
• server-trace.spec.tsx › Server-Timing at head commit › respects a name the app already wrote: the app's own traceparent entry is replaced by the generated one

httpStatus/httpHeader retract their declaration in onCleanup unless response.committed, and the documented commit point for a renderToString result is createSSRResponse, which runs after renderToString returns. The first test notes that it relies on the deferred dispose. Disposing synchronously retracts the declarations before anything commits them.

I can see two ways to keep both, and each changes something you may care about:

1. Commit the event's response head inside renderToString, right before disposing, the way an awaited renderToStream commits before its final dispose. createSSRResponse would then pass the committed stub through, but this moves the documented commit point, and a header write between renderToString and createSSRResponse would hit commitResponseStub's post-commit guard (throws in dev).
2. Keep the head open and let the declarations of a finished render outlive its dispose (for example, drop them from the ledgers without restoring when renderToString completes), so only the reactive nodes are released early.

Which direction would you prefer? Happy to put up a PR for either. I have a spec that renders five times in a loop and checks that each render's onCleanup has run before the next one starts (it fails on next today), plus one for a render that throws.