[lxsmnsyc]

The unknown-id 404 (#3110) catches a function that a deploy removed or renamed. It cannot catch one whose id survived the deploy but whose arguments or result changed shape, because ids hash the file path and the name, not the body. This adds an opt-in build id check on the server for that case. It is the core version of solidjs/solid-start#2363.

// server entry
configureServerFunctionsServer({ buildId: BUILD_ID });

// client entry, added by the build integration (vite plugin)
configureServerFunctionsClient({
  prepareRequest(init) {
    if (init.method?.toUpperCase() === "GET") return init;
    return { ...init, headers: { ...init.headers, "X-Server-Function-Build": BUILD_ID } };
  }
});

Changes

• Add BUILD_HEADER (X-Server-Function-Build) to the shared layer. It is not exported from either entry.
• Add buildId to the server config. A call whose header names another build gets 409, with the server's id under the same header and Cache-Control: no-store. The arguments are not parsed and the function does not run.
• The 409 also carries the unknown-function label (X-Server-Function-Unknown). The client rejects it with unknownFunction: true, the same as the unknown-id 404. There is one skew signal for integrations to check.
• The client runtime is unchanged and adds 0 bytes. The build integration knows the build id and adds the header through prepareRequest. Platform skew protection, such as pinning a deployment by header or cookie, fits the same hook.
• The check runs after the origin gate, unlike the unknown-id 404.
• Calls without the header are not checked. A server with no buildId checks nothing.
• Add the header to the preflight's default allowed headers. The CORS answer already exposes every response header, so cross-origin clients can read the label.
• Document the option next to the unknown-id paragraph in 10-server-functions.md.

Testing

• New test/server/server-functions-build-id.spec.tsx (6 tests) runs against the built bundles. It covers the refusal, a matching build, a call without the header, a server without an id, the client error flag through a prepareRequest hook, and a matching build through the client.
• All 62 server-function spec files pass.
• The server suite passes except link-claim.spec.tsx and lowercase-on-attribute.spec.tsx. These fail the same way without this change in my local setup, which has a stale compiler build.

🤖 Generated with Claude Code

[changeset-bot]

🦋 Changeset detected

Latest commit: 89a61a7

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 14 packages

Name	Type
@solidjs/web	Patch
@solidjs/babel-plugin	Patch
@solidjs/diagnostics	Patch
@solidjs/element	Patch
@solidjs/h	Patch
@solidjs/html	Patch
test-integration	Patch
board-example	Patch
server-dbmon-example	Patch
todos-server-example	Patch
@solidjs/compiler	Patch
@solidjs/signals	Patch
solid-js	Patch
@solidjs/universal	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codspeed]

Merging this PR will not alter performance

1 warning

⚠️ 3 benchmarks are dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

✅ 196 untouched benchmarks
⏩ 5 skipped benchmarks¹

---

_{Comparing lxsmnsyc:feat/server-function-skew (89a61a7) with next (1c0ff9f)}

Footnotes

1. 5 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[ryansolid]

Direction from Ryan for this one: keep the server-side check in core, and move the client half out of the transport.

• Size: as written, the transport change costs every server-function app +354 B minified, even with no buildId, and it fails the Size check on six scenarios, including the frozen base and live server components floors.
• One skew signal: a build mismatch is the same situation as the unknown-id 404: this client came from another build, so reload. Have the 409 carry the existing unknown-function label (UNKNOWN_HEADER) so the client surfaces it as unknownFunction. Then there's no new client response code and no second versionSkew flag, and integrations check one thing.
• The header comes from the integration: the vite plugin knows the build id, and it can add the header through prepareRequest. That keeps client bytes at 0, keeps BUILD_HEADER out of the public exports, and leaves room for platform skew protection (Vercel-style deployment pinning by header or cookie) as just another prepareRequest.

The server check itself (after the origin gate, before the body is read, skipped without a header or without a server buildId) looks right, and the CORS change is safe.

— Claude via Claude Code

---

Generated by Claude Code

[lxsmnsyc]

Moved the client half out of the transport, as suggested.

• The client runtime is unchanged, so client bytes are 0. BUILD_HEADER is no longer exported.
• The 409 carries X-Server-Function-Unknown, so the client reports it as unknownFunction. There is no versionSkew flag.
• The integration adds X-Server-Function-Build through prepareRequest and skips GET-encoded reads. The spec does the same with a small helper.
• The server check, its position, and the CORS change are as before.

Two open questions for the integration side:

• prepareRequest is a single hook, and configureServerFunctionsClient replaces it. If the vite plugin installs the build id hook and the app later sets its own (a bearer token, for example), the build id is dropped without an error. The reverse order drops the app's hook. Core does not expose the current hook, so the plugin cannot wrap it. Should the plugin own composition (the app passes its hook to the plugin), or should core add a way to compose hooks?
• With BUILD_HEADER out of the exports, the plugin hard-codes "X-Server-Function-Build". That works if the name is a stable wire contract. Should the docs say so?

🤖 Generated with Claude Code