2.0.0-beta.30 | createStore with `{ssrSource:"server"}` and async store function is not awaited

[mizulu]

Describe the bug

{ssrSource:"server"} with an async store function is not respected
and the clients sees an empty store on the initial render.

additionally the client side, runs the store function as well.

With a sync store function, this problem does not exists.
and works as expected. client first render is the server value
and no hydration causes the store to evaluate again client side. as part of the hydration.

Your Example Website or App

https://s.olid.uk/id/omIbsbbhQ-uQuTV6DID1rQ

Steps to Reproduce the Bug or Issue

sync store with {ssrSource:"server"} properly renders
the server value and does not run the store function client side when hydrating

however an async store, the ssr render does not await the store, and render nothing.
and does run the client side store function.

in the reproduction

sync store case

renders
Sync:fromServer

as expected, and does not update to the fromClient

async store case

renders
"Async:"

and after 4 seconds renders
"Async:fromClient"

instead of the expected:

• fromServer renders from the ssr output, and do not run the client side function that updates its to fromClient
  same as the sync version.

Expected behavior

both async/sync store function should behave the same when using {ssrSource:"server"}
and render the initial server side value of the store.

Screenshots or Videos

Platform

• OS: [e.g. macOS, Windows, Linux]
• Browser: [e.g. Chrome, Safari, Firefox]
• Version: [e.g. 91.1]

Additional context

import { render, isServer } from '@solidjs/web';
import { createSignal, createStore, Loading } from 'solid-js';

export default function App() {

  const [s, ss] = createStore(() => {

    return { message: isServer ? "fromServer" : "fromClient" }
  }, { message: "Serv" }, { ssrSource: "server" })


  const [s2, ss2] = createStore(async () => {
    if (!isServer) {
      await new Promise(r => setTimeout(r, 4000))
    }
    return { message: isServer ? "fromServer" : "fromClient" }
  }, { message: "Serv" }, { ssrSource: "server" })


  const [count, setCount] = createSignal(0);
  return (
    <div class="p-2">
      <div>
        <b>Sync:</b>
        <Loading>
          {s.message}
        </Loading>
      </div>
      <div>
        <b>Async:</b>
        <Loading>
          {s2.message}
        </Loading>
      </div>
      <button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded" onClick={() => setCount(count() + 1)}>
        Count: {count()}
      </button>
    </div>
  );
}


if (typeof document !== 'undefined') {
  render(() => <App />, document.getElementById('root')!);
}

[ryansolid]

Fixed on next (a60b288), releasing in the next beta.

Root cause: the server createStore dropped its options argument when delegating to the projection machinery, so ssrSource: "server" never reached it. With options forwarded, the async source is awaited during streaming SSR, the settled state is serialized into the hydration payload, and the client adopts it without re-running the source. A parity-harness scenario probes this with an isServer-branching source — the settled client DOM keeps the server value.

One clarification on the sync case: it behaves as designed, and serialization stays async-only. For a synchronous source the code itself is the value transport — the client re-runs it against hydrated inputs and reproduces the value, so nothing needs to ride the payload (ssrSource: "server" is the default spelled out). That does mean a sync source that branches on the environment (e.g. isServer) can produce a different value client-side, but that's a violation of the purity contract sync computes live under generally, not something specific to stores or ssrSource — the same is true of a plain memo. Server-only values that the client must adopt verbatim are exactly what the async path (or serialized props) is for.