You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Session resurrection: framework support for rebuilding sessions across restarts #49
Splitting this issue (2026-08-22). "Persistent sessions" conflated two different things with different mechanisms and different timelines:
This issue (near term): session resurrection. Persist not the session object graph but the facts needed to rebuild it — a durable auth token mapping to a user; on post-restart arrival, a new session is constructed through the normal constructor and re-populated from those facts. Pages die (page-expired; the planned tombstone mechanism applies), but the user stays logged in and lands on their feet.
This is what just about every app already hand-rolls today, which is exactly the argument for making it a framework feature: one durable-token hook plus the session-rebuild seam, instead of N per-app implementations. It requires no serialization technology at all, is immune to class-shape drift across deploys (the persisted artifact is a token and a user ID, not an object graph), and composes with the construction-order principle (sessions are constructed, never magically reanimated).
Split off as a separate issue: marshalling-era page cache serialization — deliberately waiting for Java's marshalling work, and even then scoped skeptically (see the new issue for the framing: it's really just expanded resurrection).
Dependency: any form of session survival across restarts arms the NGSwitchComponent elementID-ordering flaw (first-encounter-order name→ID minting is traffic-dependent across JVM instances/restarts) — #47 must land first.
Activity
NGSwitchComponent: fix elementID-minting race, document the ordering …
[-]Persistent sessions[/-][+]Session resurrection: framework support for rebuilding sessions across restarts[/+]hugithordarson commentedon Aug 22, 2026
Splitting this issue (2026-08-22). "Persistent sessions" conflated two different things with different mechanisms and different timelines:
This issue (near term): session resurrection. Persist not the session object graph but the facts needed to rebuild it — a durable auth token mapping to a user; on post-restart arrival, a new session is constructed through the normal constructor and re-populated from those facts. Pages die (page-expired; the planned tombstone mechanism applies), but the user stays logged in and lands on their feet.
This is what just about every app already hand-rolls today, which is exactly the argument for making it a framework feature: one durable-token hook plus the session-rebuild seam, instead of N per-app implementations. It requires no serialization technology at all, is immune to class-shape drift across deploys (the persisted artifact is a token and a user ID, not an object graph), and composes with the construction-order principle (sessions are constructed, never magically reanimated).
Split off as a separate issue: marshalling-era page cache serialization — deliberately waiting for Java's marshalling work, and even then scoped skeptically (see the new issue for the framing: it's really just expanded resurrection).
Dependency: any form of session survival across restarts arms the NGSwitchComponent elementID-ordering flaw (first-encounter-order name→ID minting is traffic-dependent across JVM instances/restarts) — #47 must land first.