2.0.0-beta.15 Many hydration bugs

[dangkyokhoang]

Describe the bug

Bug 1: Plain simple hydration issue. Try clicking Refreshing several times.
Bug 2: JSX syntax {data().value && <h4>{data().value}</h4>} causes bug in createMemo order. keyFn memo returns an object instead of the path string. See console logs.
Bug 3: Loading > Errored > Nested async memo causes the page to load forever. SSR stream transform exceeded maximum lifetime (120000ms), forcing cleanup
Bug 4: createEffect on async memo causes the page to load forever.
Bug 5: Reusing promise stored in global cache doesn't work.
Bug 6: Rendering {data()} where data() is an object causes infinite loop. Does not loop but logs errors in Vite Nitro SSR reproduction.

Your Example Website or App

Tanstack SSR
https://stackblitz.com/edit/solidjs-templates-jskxvhkj?file=src%2Froutes%2Fhydration-bug-1.tsx

Vite Nitro SSR
https://stackblitz.com/edit/nitrojs-nitro-6gibxz9z?file=src%2Froutes%2Findex.tsx

Steps to Reproduce the Bug or Issue

Go the the link above.

Expected behavior

No bugs.

Screenshots or Videos

No response

Platform

Doesn't matter.

Additional context

No response

[brenelz]

It would be helpful to see if you could replicate these outside of Tanstack Start if possible. That way we know whether the issue is in solid core or tanstack

[brenelz]

SolidJS 2.0.0-beta.15 — Hydration Bug Findings

Reproduced and traced all six bugs on 2.0.0-beta.15 (SSR + TanStack Start).
Method: reproduce locally, drive SSR with curl and hydration with Playwright/Chrome,
then trace into the framework source.

Summary

#	Verdict	Where	Cause (simple)	Fix / workaround
1	Real bug	@solidjs/web (hydration)	Tracked node drifts from the real DOM node	needs runtime fix
2	Real bug	babel-plugin-jsx-dom-expressions	Server and client number hydration keys differently	use <Show> instead of &&
3	Real bug	solid-js SSR	Error boundary re-throws "pending" and loops forever	runtime patch
4	Real bug	solid-js SSR	Effect re-throws "pending" and loops forever	runtime patch / ssr:false
5	Footgun	hydration design	App caches a fake promise made during hydration	app-side guard / ssr:false
6	Real bug	@solidjs/web SSR	Rendering a plain object crashes SSR, then loops on client	runtime patch

---

Bug 1 — Refresh leaves a duplicated value

Not a compiler bug. When an async value sits directly inside <Loading> next to other
siblings, the runtime loses track of the hydrated DOM node. On the first refresh(),
the old value's tracked node is already detached (parentNode === null), so it can't be
removed — the new value is added and the old one stays as a ghost. Wrapping the value in a
<div> avoids it.

Bug 2 — {cond && <jsx>} before <For> breaks hydration

Server and client compile the same JSX but assign hydration keys (_hk) in a different
order when a && expression is followed by a <For>. The client looks for keys the server
never wrote, so the nodes can't be claimed. Not related to async. Workaround: use <Show>
instead of &&.

Bug 3 — Loading > Errored > async hangs forever

The SSR error boundary turns "still loading" into a thrown error, which makes the Loading
boundary re-render the whole subtree on every cycle. That recreates the async work each time,
so it never finishes. Passing the pending state through (instead of throwing) fixes it.

Bug 4 — createEffect reading an async memo hangs forever

The effect reads a not-yet-ready async value and throws. Because the effect runs outside the
Loading JSX, the throw escapes and makes an outer Loading re-render forever. Effects don't
produce SSR output, so the fix is to swallow that "not ready" instead of aborting the render.
ssr: false also works.

Bug 5 — Reusing a cached promise doesn't work

During hydration Solid swaps the global Promise for a fake one (MockPromise) that never
resolves, since the real value comes from serialized data. If your app stores that promise in
a cache, the cache now holds a dead stub. Navigating back reuses it and <Loading> waits
forever. Fix: don't cache a promise created during the hydration render, or guard with
instanceof Promise. ssr: false also works.

Bug 6 — Rendering an object causes an infinite loop

Rendering {data()} where data() is a plain object crashes SSR (it assumes the object is an
internal node), which corrupts the stream and makes the client loop endlessly. Making SSR skip
and warn on an unrenderable object — like the client already does — fixes both the crash and
the loop.

[dangkyokhoang]

I've updated the issue description with a minimal Vite SSR reproduction repo: https://stackblitz.com/edit/nitrojs-nitro-6gibxz9z?file=src%2Froutes%2Findex.tsx

On the bug 5, I think this should be considered a bug. Users would not expect a promise from fetch to never resolve. And Seroval can serialize Promise.

[ryansolid]

5 is a consequence of the hydration design and is not really avoidable at this stage. It isn't about serialization of promises. Seroval does serialize the promise, but that the deps need to be discovered on the client otherwise no future reactivity will work. So the fn needs to run on the client even though any promise created during the hydration run will be thrown away and replaced with the serialized one. Its not that we can just swap the seroval one in the user code either, because seroval only serializes the whole final promise and your assignment could be an internal midexecution part of the promise. Maybe we can error and make this more obvious.

The recommended approach here for caching libraries is call serialization api's yourself which hang off sharedConfig, and rely on serovals deduping to avoid over serialization. Then using hydration flags to determine when to go that path. These APIs are not exactly publicly documented and I was hoping to work with the Start teams on finalizing the shape, albeit they aren't currently different than 1.x and this was the approach Solid Router did with createAsync.

[dangkyokhoang]

So a workaround until then, if the promise I'm trying to access is the promise returned from createMemo fn then I can just:

client.store.set(
  id,
  // (sharedConfig.hydrating && sharedConfig.load?.(getOwner()!.id!)) || fetchData(id),
  sharedConfig.hydrating ? sharedConfig.load!(getOwner()!.id!) : fetchData(id),
);

Is this safe?