Repository navigation
NodeJS OOM crashes with Solid V2 when ssr: true #3003
Description
Describe the bug
OOM crash, when ssr: true, see below.
It doesn't seem to crash if ssr: false.
Your Example Website or App
https://github.com/Ciantic/test-blog
Steps to Reproduce the Bug or Issue
- Clone this: github.com/Ciantic/test...
- pnpm run build, pnpm run serve
- Navigate to localhost:4173/blog/asdfadsf or http://localhost:4173/blog/some-post/ and it freezes and crashes
➜ test-blog git:(main) ✗ $ pnpm run serve
$ vite preview
➜ Local: http://localhost:4173/
➜ Network: use --host to expose
➜ press h + enter to show help
<--- Last few GCs --->
[819888:0x55d5203a9000] 32831 ms: Scavenge (interleaved) 4051.7 (4104.2) -> 4047.0 (4121.7) MB, pooled: 0 MB, 9.39 / 0.00 ms (average mu = 0.217, current mu = 0.168) allocation failure;
[819888:0x55d5203a9000] 33940 ms: Mark-Compact (reduce) 4060.4 (4123.0) -> 4049.9 (4096.0) MB, pooled: 0 MB, 82.92 / 0.00 ms (+ 991.0 ms in 199 steps since start of marking, biggest step 5.0 ms, walltime since start of marking 1110 ms) (average mu = 0
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
1: 0x7f564964507a node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/lib64/libnode.so.137]
2: 0x7f564ab7a26c [/lib64/libnode.so.137]
3: 0x7f564ae7fedb [/lib64/libnode.so.137]
4: 0x7f564ae7ffff [/lib64/libnode.so.137]
5: 0x7f564ae801d7 [/lib64/libnode.so.137]
6: 0x7f564ae99a09 [/lib64/libnode.so.137]
7: 0x7f564ae9e164 [/lib64/libnode.so.137]
8: 0x7f564bb43447 [/lib64/libnode.so.137]
[ELIFECYCLE] Command failed.
[1] 819877 IOT instruction (core dumped) pnpm run serveExpected behavior
I expect NodeJS not to crash.
Platform
- OS: Linux
- Node version: 24.18.0
Activity
brenelz commentedon Aug 16, 2026
So this seems to be some kind of bug. If you add a Loading boundary in
[slug].tsxit seems to work.Ciantic commentedon Aug 17, 2026
I wonder why
users/[id].tsxworks, it doesn't have Loading, and it has Title. Theblog/[slug].tsxis direct 'copy' of it but just with dummy blog posts.brenelz commentedon Aug 17, 2026
Its becuase it doesn't have an async value in the title
<Title>{User ${props.params.id} - Solid App}</Title>fix(solid): converge SSR retry discovery for unstable promise identit…
ryansolid commentedon Aug 17, 2026
Fixed on
nextin 8366208.Root cause was in Solid's SSR retry discovery, triggered by the combination in this app:
<Title>/body reading a memo over the router'squery(). For a cached key,query()returns a fresh derived promise object on every call — perfectly legal, but discovery relied on stamping settlement state onto the promise object itself, so no retry pass ever recognized the work as settled. The loop re-ran at microtask speed, allocating a new serialized deferred per pass until the heap died. (That's whyusers/[id]was fine — its<Title>is synchronous, so nothing ever suspends.)The fix makes convergence independent of promise identity: the render context now keeps per-slot flight records keyed by owner id, so re-created slots adopt settled answers synchronously or join the in-flight deferred (one serialization per slot, and it settles even if the creating node was superseded — solid-meta's head registry re-pulls holes mid-flight, which previously could leave a serialized deferred dangling and hold the stream open). A retry budget also fails genuinely non-convergent boundaries loudly instead of OOMing.
Verified against this reproduction repo with
ssr: true:/blog/asdfadsfand/blog/hello-solidnow render correctly and close the stream in a few milliseconds. Thanks for the tight repro!Give server createProjection slot memory so pending body reads conver…