Skip to content

[2.0 rc.14 / next] A synchronous prepareRequest hook makes every hydrated server-function read refetch in the browser #3959

Closed

Description

@rvlzzr

Summary

With any prepareRequest configured, even an identity hook init => init, a page whose data comes from server functions fetches that data twice: once during SSR, and again from the browser right after hydration, although the serialized value was adopted. Without the hook there is no client request.

Reproduces on 2.0.0-rc.14 and on next at 358159c.

Reproduction

// client entry, before render
import { configureServerFunctionsClient } from "@solidjs/web/server-functions/client";
configureServerFunctionsClient({ prepareRequest: init => init });
// a page reading a "use server" function through a memo or derived store
const value = createMemo(() => readThing());
return <p>{value()}</p>;

Load the page directly (SSR, then hydrate) and watch the network:

prepareRequest SSR reads Client requests after hydration
not configured 1 0
init => init 1 1

The DOM is adopted correctly in both cases; the extra request is wasted (and, for private reads, doubles server work on every page load).

Cause

Hydration runs a serialized source's compute once, synchronously, inside subFetch (packages/solid/src/client/hydration.ts), with window.fetch swapped for a never-settling mock, then restores it. The server-function transport's createRequest (packages/web/server-functions/src/client.ts) does:

if (config.prepareRequest) {
  const prepared = await config.prepareRequest(init, { id, meta });

The await runs even when the hook returns synchronously, so send(base, init) happens a microtask later, after subFetch has restored the real fetch. The call goes to the network instead of the mock.

Fix

Await only when the hook returns a promise:

-    const prepared = await config.prepareRequest(init, { id, meta });
+    let prepared = config.prepareRequest(init, { id, meta });
+    if (typeof (prepared as PromiseLike<RequestInit>)?.then === "function") prepared = await prepared;

A synchronous hook then sends inside the hydration window like the default transport. An async hook still awaits, so it keeps the current behaviour (an async hook will always miss the synchronous window; that may be worth documenting). With this change the table above shows 0 client requests for both rows, for memo and store sources, sync and async. @solidjs/web's client, server and hydration test suites pass unchanged. I can open a PR.

(submitted by Claude Opus 5.5 on behalf of rvlzzr)

Activity

  1. ryansolid commented on Oct 12, 2026

    @ryansolid
    Member

    Fixed by #3990 (from #3988 by @brenelz, merged to next as c2d4571): a synchronous prepareRequest hook now sends in the calling tick, so an adopted read stays inside hydration instead of refetching. An async hook is still awaited and still refetches, and the docs say so. A read whose arguments go through the rich-argument codec still refetches, because of await serializeArguments; that is a separate follow-up.

    — Claude via Claude Code


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions