Problem
Several exported functions — signOut, saveSession, refreshSession, switchToOrganization — internally call getSessionStorage(), which throws "SessionStorage was never configured" if configureSessionStorage hasn't already run. Today the only way to ensure that is to have authkitLoader run first, since configureSessionStorage isn't part of the public API.
This works well for the common case where authkitLoader runs in a root or layout loader before anything else. But it breaks down for flows that don't go through authkitLoader:
Logout without a prior loader
A direct hit to /logout (cold start, serverless environment, or a route that doesn't nest under a layout with authkitLoader) calls signOut() → terminateSession() → getSessionStorage() and throws.
The natural workaround — calling authkitLoader({ ensureSignedIn: false }) as a setup step — introduces a functional risk: if the user has an expired session and the refresh token exchange fails (network error, revoked token, WorkOS outage), updateSession throws SessionRefreshError, and authkitLoader's catch block redirects to the sign-in page. The user clicked "log out" but gets sent to "log in" with their broken session still intact. Logout is the one flow that should be most robust when session state is broken.
Custom callback flows
PR #52 added saveSession for manual auth flows, but saveSession also calls getSessionStorage(). A callback route that uses authenticateWithCode + saveSession directly (rather than the built-in authLoader) will throw on cold starts for the same reason — as originally reported in authkit-remix#63 and fixed for authLoader in PR #22.
Suggestion
Export configureSessionStorage (and optionally getSessionStorage) from the package's public API so consumers can call it directly at the boundaries that need it, without depending on authkitLoader having run first.
Happy to put together a PR for this if it fits the direction you're heading. Thanks for a great library!
Problem
Several exported functions —
signOut,saveSession,refreshSession,switchToOrganization— internally callgetSessionStorage(), which throws"SessionStorage was never configured"ifconfigureSessionStoragehasn't already run. Today the only way to ensure that is to haveauthkitLoaderrun first, sinceconfigureSessionStorageisn't part of the public API.This works well for the common case where
authkitLoaderruns in a root or layout loader before anything else. But it breaks down for flows that don't go throughauthkitLoader:Logout without a prior loader
A direct hit to
/logout(cold start, serverless environment, or a route that doesn't nest under a layout withauthkitLoader) callssignOut()→terminateSession()→getSessionStorage()and throws.The natural workaround — calling
authkitLoader({ ensureSignedIn: false })as a setup step — introduces a functional risk: if the user has an expired session and the refresh token exchange fails (network error, revoked token, WorkOS outage),updateSessionthrowsSessionRefreshError, andauthkitLoader's catch block redirects to the sign-in page. The user clicked "log out" but gets sent to "log in" with their broken session still intact. Logout is the one flow that should be most robust when session state is broken.Custom callback flows
PR #52 added
saveSessionfor manual auth flows, butsaveSessionalso callsgetSessionStorage(). A callback route that usesauthenticateWithCode+saveSessiondirectly (rather than the built-inauthLoader) will throw on cold starts for the same reason — as originally reported in authkit-remix#63 and fixed forauthLoaderin PR #22.Suggestion
Export
configureSessionStorage(and optionallygetSessionStorage) from the package's public API so consumers can call it directly at the boundaries that need it, without depending onauthkitLoaderhaving run first.Happy to put together a PR for this if it fits the direction you're heading. Thanks for a great library!