chore(deps): bump @supabase/ssr to ^0.10.2 + supabase-js to ^2.104.0 - #841
Merged
Conversation
@supabase/ssr 0.8.0 has an SSR race condition where the GoTrue client auto-initializes asynchronously and can hijack the cookie-writing path after exchangeCodeForSession. The symptom in our setup: /token returns 200, data.session is populated, but the SSR client never invokes the cookies.setAll callback — so session cookies never reach the response. Our diagnostic patch (#840) surfaced this exact branch as ?reason=no_pending_cookies. Fixed upstream in 0.8.1 via skipAutoInitialize: true (PR #131). Bumping to latest 0.10.2 picks up that fix plus 0.10.0's setAll cache headers, which prevent proxies/CDNs from caching auth responses. @supabase/supabase-js bumped to ^2.104.0 to satisfy the new peer requirement (ssr 0.10.2 needs ^2.102.1). No breaking changes in either package in the traversed range — createServerClient, createBrowserClient, exchangeCodeForSession, getSession, getUser, onAuthStateChange all retain their signatures. No source changes — package.json + pnpm-lock.yaml only.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
tran-christian
marked this pull request as draft
April 22, 2026 03:23
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
tran-christian
marked this pull request as ready for review
April 22, 2026 03:26
4 tasks
tran-christian
added a commit
that referenced
this pull request
Apr 22, 2026
…ug cookie (#842) With the root cause fixed in #841, the browser-side auth_debug cookie from #840 has served its purpose — it was one-off scaffolding to prove the pipeline carries cookies end-to-end. Replacing it with server-side error logs in Vercel's runtime log viewer: zero client footprint, no leaked deployment details to analytics/replay scripts, full context when things actually go wrong. next.config.js: removeConsole in prod now uses { exclude: ['error'] } so console.error survives compilation. console.log/warn/info/debug are still stripped. DEBUG_AUTH=1 continues to disable stripping entirely for local `pnpm build && pnpm start` repro. app/auth/callback/route.ts: - Shared `diag` object captures the same fields the auth_debug cookie carried (forwardedHost, pendingCookieCount, pendingCookieNames, requestCookieNames, publishableKeyPrefix, origin, hasSession, hasUser) plus SDK-side signals. - Every abnormal branch logs `[auth/callback] reason=<branch>` with `diag` to console.error. exchange_failed also includes the SDK message + status. no_code is not logged (crawler noise). - auth_debug cookie + debugPayload construction removed. - DEBUG_AUTH-gated console.log block removed — its content is a subset of `diag` and only fires now when something is actually wrong. - Unused `oauth_error` option removed from failureRedirect's union.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #840. The diagnostic patch we merged yesterday surfaced the exact failure branch:
/?error=auth_callback_error&reason=no_pending_cookies. That meansexchangeCodeForSessionreturned successfully withdata.sessionpopulated, but@supabase/ssrnever called ourcookies.setAlladapter — so the stamped session cookies we engineered in #830 / #833 / #835 / #840 never had anything to stamp.Root cause is upstream in
@supabase/ssr@0.8.0: an SSR race condition where the underlying GoTrue client auto-initializes asynchronously and races with the cookie-writing path. Fixed upstream in 0.8.1 viaskipAutoInitialize: true. We've been pinned at 0.8.0 and missed it.What changed
@supabase/ssr:^0.8.0→^0.10.2— picks up 0.8.1'sskipAutoInitializefix plus 0.10.0'ssetAllcache headers (prevents CDN caching of auth responses on Vercel).@supabase/supabase-js:^2.91.0→^2.104.0— required byssr@0.10.2's new peer range^2.102.1.pnpm-lock.yamlregenerated.No source changes. No app code touches any removed or renamed API.
Non-breaking confirmation
Verified against both changelogs:
@supabase/ssr0.8.0 → 0.10.2.@supabase/supabase-js2.91 → 2.104 forcreateClient,createServerClient,createBrowserClient,signInWithOAuth,signInWithOtp,exchangeCodeForSession,getSession,getUser,getClaims, oronAuthStateChange.onAuthStateChangecallback insrc/context/AuthContext.tsxis not async, so the 2.74.0 async-callback deprecation doesn't affect us.Test plan
/with session, welcome toast, no?error=sb-<ref>-auth-token(and chunks if present) visible withDomain=omshub.org(from fix(auth): scope session cookies to registrable domain + diagnostic reasons #840)auth_debugdiagnostic cookie showspendingCookieCount > 0(confirms the fix — this was0before)src/lib/supabase/__tests__/proxy.test.ts) still passesRollback
Revert this commit — package-only change, no app or schema changes. Prior behavior restored immediately.
Related
x-forwarded-hostredirect target fix/auth/callbackproxy exclusion (PKCE code_verifier fix)