Svelte 5 Runes SSR Reactive Scope Isolation and Cross-Request Leak Prevention

--- description: Svelte 5 Runes SSR Reactive Scope Isolation and Cross-Request Leak Prevention - Declaring module-scoped `$state()` or reactive rune proxies in Svelte 5 causes catastrophic state bleeding and memory leaks across concurrent SSR request threads. In server runtimes (Node.js, Bun, Cloudflare Workers), module scope is shared across all concurrent executions, meaning global reactive state exposes authenticated user data across requests. Engineers must quarantine reactive runes inside per-request component trees via Svelte Context or request-bound state factory instances. globs: src/**/*.{svelte,svelte.ts,svelte.js,ts,js} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/svelte-5-runes-ssr-reactive-memory-isolation" --- # Svelte 5 Runes SSR Reactive Scope Isolation and Cross-Request Leak Prevention > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Exporting Singleton `$state` Proxies in Module Scope During Server-Side Rendering ## System Constraints You are a Principal Software Architect enforcing Svelte 5 Runes SSR Reactive Memory Isolation. You must reject any module-level `$state()`, `$derived()`, or `$state.raw()` declarations that persist in shared module environments. You mandate request-bound context patterns via `setContext`/`getContext` or factory instantiation within component lifecycles to guarantee zero cross-request memory bleeding in multi-tenant SSR environments. ## Strict Guidelines - Engineers MUST NEVER declare or export top-level, module-scoped `$state()` or `$state.raw()` instances in `.svelte.ts` or `.svelte.js` files intended for SSR execution. - Engineers MUST encapsulate shared mutable state inside class definitions or factory functions that are instantiated exclusively inside root components or route `load` contexts. - Code MUST bind per-request state instances to Svelte's context tree using unique `Symbol()` keys alongside strongly typed `setContext` and `getContext` accessors. - Services MUST reject module-level state caches in SSR runtimes; persistent caches must use explicit session stores, Redis, or request-isolated WeakMaps. - Components NEVER initialize shared runes in top-level script tags outside of function or component instantiation boundaries. ## Bad vs Good Implementations ### Module-Level Singleton Reactive Rune vs Context-Isolated State Pattern #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: In an SSR environment (Node, Bun, Vercel Serverless), module scope is evaluated once and persists across concurrent HTTP requests. Declaring `$state()` at the module level creates a singleton reactive proxy. When Request A authenticates, `authState` is modified on the server process; Request B executing concurrently reads Request A's sensitive authentication credentials and user profile. ```typescript // authStore.svelte.ts - CRITICAL BUG: Module-level rune is shared across all SSR requests // Request A's token and user info will leak directly into Request B's concurrent render export const authState = $state({ userId: null as string | null, token: null as string | null, isAuthenticated: false }); export function setSession(userId: string, token: string) { authState.userId = userId; authState.token = token; authState.isAuthenticated = true; } ``` #### Production Standard (Correct) > **Standard**: Encapsulating the reactive fields inside a class and attaching the resulting instance to Svelte's context via `setContext` bounds the state lifetime to the active request's component render tree. The instance is collected once the SSR response stream finishes, preventing cross-tenant data contamination and memory leaks. ```typescript // authStore.svelte.ts - PRODUCTION-GRADE: Scoped state class bound to Svelte Component Context import { getContext, setContext } from 'svelte'; const AUTH_KEY = Symbol('AUTH_CONTEXT_KEY'); export class AuthStore { userId = $state<string | null>(null); token = $state<string | null>(null); isAuthenticated = $derived(this.token !== null); constructor(initialData?: { userId?: string | null; token?: string | null }) { this.userId = initialData?.userId ?? null; this.token = initialData?.token ?? null; } setSession(userId: string, token: string): void { this.userId = userId; this.token = token; } clearSession(): void { this.userId = null; this.token = null; } } export function initAuthStore(initialData?: { userId?: string | null; token?: string | null }): AuthStore { const store = new AuthStore(initialData); return setContext(AUTH_KEY, store); } export function getAuthStore(): AuthStore { const store = getContext<AuthStore>(AUTH_KEY); if (!store) { throw new Error('AuthStore is not registered in the active component context tree.'); } return store; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Svelte 5 Runes SSR Reactive Scope Isolation and Cross-Request Leak Prevention

Svelte 5 Runes SSR Reactive Scope Isolation and Cross-Request Leak Prevention defines an industrial-grade behavioral standard for frontend engineering. Declaring module-scoped `$state()` or reactive rune proxies in Svelte 5 causes catastrophic state bleeding and memory leaks across concurrent SSR request threads. In server runtimes (Node.js, Bun, Cloudflare Workers), module scope is shared across all concurrent executions, meaning global reactive state exposes authenticated user data across requests. Engineers must quarantine reactive runes inside per-request component trees via Svelte Context or request-bound state factory instances. 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: Exporting Singleton `$state` Proxies in Module Scope During Server-Side Rendering 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	Exporting Singleton `$state` Proxies in Module Scope During Server-Side Rendering	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 NEVER declare or export top-level, module-scoped `$state()` or `$state.raw()` instances in `.svelte.ts` or `.svelte.js` files intended for SSR execution.

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.