SolidStart 1.0 Server Functions (`server$`) & Async Boundary Invariants

--- description: SolidStart 1.0 Server Functions (`server$`) & Async Boundary Invariants - Enforces strict isolation between client reactive signals and SolidStart 1.0 `server$` RPC functions across network boundaries. Prevents non-serializable closure captures, client-side secret leakage, and broken fine-grained reactivity when bridging `createResource` or async primitives with server-side executions. globs: src/**/*.{ts,tsx} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/solidstart-server-functions-and-async-boundaries" --- # SolidStart 1.0 Server Functions (`server$`) & Async Boundary Invariants > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Capturing Reactive Client Signals in server$ Closures or Omitting createResource/Suspense Async Boundaries ## System Constraints You are a Principal Engineer enforcing SolidStart 1.0 Server Functions & Async Boundaries. Mandate that server$ functions remain pure RPC endpoints with explicit serialized inputs, never implicitly close over reactive client signals or DOM state, and are always mediated via createResource or createAsync within a Suspense/ErrorBoundary boundary. ## Strict Guidelines - Engineers MUST ALWAYS pass client-side reactive state explicitly as serializable arguments into `server$` invocations rather than referencing external signals directly within the `server$` function body. - Engineers MUST wrap all async data-fetching `server$` calls in SolidStart's reactive primitives (`createAsync` or `createResource`) and mount them inside `<Suspense>` and `<ErrorBoundary>` components. - Engineers MUST NOT reference client-only variables (e.g., `window`, `document`, reactive signals declared outside `server$`) inside the lexical scope of a `server$` body, as this breaks RPC compilation and serialization. - Code SHOULD enforce input schema validation (e.g., via Valibot or Zod) at the entry point of every `server$` function to guarantee contract safety across the untrusted network boundary. - Components NEVER trigger raw asynchronous `server$` mutations directly inside render tracking scopes without tracking pending state via `useAction` or `createTransition` to prevent tearing and stale signal states. ## Bad vs Good Implementations ### Capturing Reactive Signal in server$ Closure vs Explicit Serialized Argument Passing #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Referencing the `userId()` signal directly inside the `server$` closure causes SolidStart's compiler to fail or produces an unpredictable runtime state, as the closure body is extracted into an independent HTTP RPC endpoint executed solely on the server. ```typescript import { createSignal } from "solid-js"; import { server$ } from "@solidjs/start/server"; export function UserProfile() { const [userId] = createSignal("usr_1234"); // CRITICAL ANTI-PATTERN: userId() signal is closed over directly inside server$. // This causes compilation failure or bundles client reactive tracking into server RPC boundary. const fetchUser = server$(async () => { const id = userId(); // Leaks/breaks reactive context across RPC boundary return await db.users.findUnique({ where: { id } }); }); return <div>...</div>; } ``` #### Production Standard (Correct) > **Standard**: The `getUserById` server function is declared at the module scope with explicit runtime input validation. Reactive signal dependencies are tracked in the client accessor provided to `createAsync`, properly isolated from the RPC transport and suspended via `<Suspense>`. ```typescript import { createSignal, Suspense, Show } from "solid-js"; import { createAsync } from "@solidjs/router"; import { server$ } from "@solidjs/start/server"; import * as v from "valibot"; const UserIdSchema = v.pipe(v.string(), v.nonEmpty()); // Pure, decoupled RPC endpoint with runtime validation const getUserById = server$(async (id: string) => { const parsedId = v.parse(UserIdSchema, id); return await db.users.findUnique({ where: { id: parsedId } }); }); export function UserProfile() { const [userId, setUserId] = createSignal("usr_1234"); // Signal passed via reactive accessor into createAsync const user = createAsync(() => getUserById(userId())); return ( <Suspense fallback={<p>Loading profile...</p>}> <Show when={user()} fallback={<p>User not found</p>}> {(userData) => <h1>{userData().name}</h1>} </Show> </Suspense> ); } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: SolidStart 1.0 Server Functions (`server$`) & Async Boundary Invariants

SolidStart 1.0 Server Functions (`server$`) & Async Boundary Invariants defines an industrial-grade behavioral standard for frontend engineering. Enforces strict isolation between client reactive signals and SolidStart 1.0 `server$` RPC functions across network boundaries. Prevents non-serializable closure captures, client-side secret leakage, and broken fine-grained reactivity when bridging `createResource` or async primitives with server-side executions. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Capturing Reactive Client Signals in server$ Closures or Omitting createResource/Suspense Async Boundaries Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Capturing Reactive Client Signals in server$ Closures or Omitting createResource/Suspense Async Boundaries	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS pass client-side reactive state explicitly as serializable arguments into `server$` invocations rather than referencing external signals directly within the `server$` function body.

Engineers MUST ALWAYS pass client-side reactive state explicitly as serializable arguments into `server$` invocations rather than referencing external signals directly within the `server$` function body.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.