Svelte 5 Universal Runes SSR Memory Retention & Cross-Request Contamination Guardrail

--- description: Svelte 5 Universal Runes SSR Memory Retention & Cross-Request Contamination Guardrail - Enforces strict isolation of universal reactive runes ($state, $derived) within request and component lifecycles in Svelte 5 SSR environments. Module-level reactive rune instantiations persist across concurrent HTTP requests in Node.js/Bun/Deno runtimes, causing critical multi-tenant data leaks and unbounded memory retention. All shared reactive state MUST be scoped to Svelte contexts, request events, or per-instance class closures. 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/svelte5-universal-runes-ssr-leak-guardrail" --- # Svelte 5 Universal Runes SSR Memory Retention & Cross-Request Contamination Guardrail > **Severity**: CRITICAL | **Category**: frontend > **Anti-Pattern Warning**: Global Module-Level Rune Declarations Leaking Multi-Tenant State and Retaining Memory in SSR Runtimes ## System Constraints You are a Principal Software Architect enforcing Svelte 5 universal rune safety across Server-Side Rendered (SSR) architectures. In Svelte 5, runes ($state, $derived, $effect) can exist in universal .svelte.ts/.svelte.js files. Module-level declarations execute once per server process, NOT once per HTTP request. You must strictly reject any module-scope reactive allocation that exposes mutable cross-tenant state or retains SSR subscriber graphs across requests. Mandate context-bound or request-scoped instantiations. ## Strict Guidelines - Engineers MUST NOT declare top-level mutable runes (`$state`, `$state.raw`, `$derived`, `$derived.by`) directly in module scope within `.svelte.ts` or `.svelte.js` files. - Engineers MUST ALWAYS encapsulate stateful universal runes within factory functions or instantiable classes managed via `setContext` and `getContext` inside the component tree or SvelteKit `event.locals`. - Components NEVER import singleton mutable reactive stores or objects across route boundaries in SSR mode. - Code SHOULD enforce strict type-safe Context API keys using `Symbol()` to guarantee that instance lookups remain unique to the active request's component tree. - Services MUST ensure that server-rendered snapshots do not attach orphaned reactive watchers or retain references to destroyed server component trees. - Engineers MUST treat any module-level reactive state export as an immediate critical security vulnerability (cross-tenant session hijacking and memory leak). ## Bad vs Good Implementations ### Module-Level Universal Rune vs. Context-Scoped Instance #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: In an SSR environment (such as SvelteKit with Node or Cloudflare adapter), `session.svelte.ts` is imported once per process worker. `currentUser` is shared across all concurrent user requests. User B will observe User A's session data if User A's render is concurrent or if `clearSession()` is omitted, leading to critical tenant state contamination and memory leak from uncollected subscriber graphs. ```typescript // src/lib/stores/session.svelte.ts - CRITICAL BUG: Module-scoped state persists across SSR requests interface UserProfile { id: string; tenantId: string; name: string; } // Module-level reactive allocations survive the request lifecycle in Node.js export const currentUser = $state<{ profile: UserProfile | null }>({ profile: null }); export function setSession(profile: UserProfile) { currentUser.profile = profile; } export function clearSession() { currentUser.profile = null; } ``` #### Production Standard (Correct) > **Standard**: By encapsulating `$state` inside the `SessionStore` class and initializing it through `setContext`, every HTTP request gets a separate instance bound to that specific component tree. When the request finishes rendering on the server, the component tree and the associated `SessionStore` instance are safely garbage-collected, eliminating memory leaks and cross-request contamination. ```typescript // src/lib/stores/session.svelte.ts - SECURE: Scoped to Svelte context per request import { getContext, setContext } from 'svelte'; interface UserProfile { id: string; tenantId: string; name: string; } export class SessionStore { #profile = $state<UserProfile | null>(null); constructor(initialProfile: UserProfile | null = null) { this.#profile = initialProfile; } get profile(): UserProfile | null { return this.#profile; } set profile(value: UserProfile | null) { this.#profile = value; } } const SESSION_KEY = Symbol('SESSION_STORE'); export function setSessionContext(initialProfile: UserProfile | null = null): SessionStore { return setContext(SESSION_KEY, new SessionStore(initialProfile)); } export function getSessionContext(): SessionStore { const store = getContext<SessionStore | undefined>(SESSION_KEY); if (!store) { throw new Error('SessionContext accessed outside of component tree or before initialization.'); } return store; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Svelte 5 Universal Runes SSR Memory Retention & Cross-Request Contamination Guardrail

Svelte 5 Universal Runes SSR Memory Retention & Cross-Request Contamination Guardrail defines an industrial-grade behavioral standard for frontend engineering. Enforces strict isolation of universal reactive runes ($state, $derived) within request and component lifecycles in Svelte 5 SSR environments. Module-level reactive rune instantiations persist across concurrent HTTP requests in Node.js/Bun/Deno runtimes, causing critical multi-tenant data leaks and unbounded memory retention. All shared reactive state MUST be scoped to Svelte contexts, request events, or per-instance class closures. 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: Global Module-Level Rune Declarations Leaking Multi-Tenant State and Retaining Memory in SSR Runtimes 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	Global Module-Level Rune Declarations Leaking Multi-Tenant State and Retaining Memory in SSR Runtimes	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 NOT declare top-level mutable runes (`$state`, `$state.raw`, `$derived`, `$derived.by`) directly in module scope within `.svelte.ts` or `.svelte.js` files.

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.