event.setHeaders() throws "header is already set" when signInWithOtp() writes PKCE verifier cookie in SvelteKit

[decasdev]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

Calling supabase.auth.signInWithOtp() from a SvelteKit form action, using the standard SvelteKit SSR cookie-handling pattern documented at https://supabase.com/docs/guides/auth/server-side/creating-a-client, throws a 500 error:

Error: "Cache-Control" header is already set at Object.setHeaders (node_modules/@sveltejs/kit/src/runtime/server/respond.js) at setAll (src/hooks.server.ts) at applyServerStorage (node_modules/@supabase/ssr/dist/main/cookies.js) at async Object.setItem (node_modules/@supabase/ssr/dist/main/cookies.js) at async setItemAsync (node_modules/@supabase/auth-js/dist/main/lib/helpers.js) at async storePKCEVerifier (node_modules/@supabase/auth-js/dist/main/lib/helpers.js) at async getCodeChallengeAndMethod (node_modules/@supabase/auth-js/dist/main/lib/helpers.js) at async SupabaseAuthClient.signInWithOtp (node_modules/@supabase/auth-js/dist/main/GoTrueClient.js)

Root cause appears to be: storing the PKCE code verifier during signInWithOtp() invokes the setAll cookie callback, which calls event.setHeaders(headers) with a Cache-Control header (per @supabase/ssr's own documented behavior of attaching cache-prevention headers to cookie-writing calls). This callback gets invoked more than once within the single signInWithOtp() call. SvelteKit's event.setHeaders() throws if called twice with the same header name in one request — unlike, e.g., a plain Headers.set(), which would just overwrite silently. So this specific combination (SvelteKit's stricter header API + @supabase/ssr calling the headers callback multiple times per auth operation) crashes.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Set up SvelteKit with @supabase/ssr, following the exact hooks.server.ts pattern from the official docs (createServerClient with getAll/setAll, calling event.setHeaders(headers) inside setAll).
2. Call supabase.auth.signInWithOtp({ email }) from a form action using the request-scoped server client from event.locals.
3. Submit the form.
4. See 500 error / stack trace above.

Expected behavior

signInWithOtp() (or any auth method that triggers cookie/header writes as a side effect, e.g. PKCE verifier storage) should not cause the setAll headers argument to be applied more than once per header name within a single request — either by not invoking the headers callback redundantly, or by documenting that consuming frameworks with strict single-set header semantics (like SvelteKit) need to dedupe headers themselves in their setAll implementation.

System information

• OS: macOS
• Version of supabase-js: 2.111.0
• Version of @supabase/ssr: 0.12.4 (latest as of testing)
• Version of Node.js: v25.2.1
• SvelteKit: 2.70.2

Additional context

Related to a similar class of issue: #144 (duplicate Set-Cookie/header calls per request), though that issue concerns multiple client instances in one request, whereas this occurs with a single client instance during a single signInWithOtp() call.

[eurlexa]

Confirming the bug.

The SvelteKit documentation reads that :"Setting the same header multiple times (even in separate load functions) is an error — you can only set a given header once." - https://svelte.dev/docs/kit/@sveltejs-kit#LoadEvent

You can follow SvelteKit team discussion in matter here sveltejs/kit#8555

Supabase introduced headers (re)setting here #176

[eurlexa]

Maybe using try catch to avoid SvelteKit automatic 500 error is better in the hooks.server.ts file:

// src/hooks.server.ts
import { PUBLIC_SUPABASE_URL, PUBLIC_SUPABASE_ANON_KEY } from '$env/static/public'
import { createServerClient } from '@supabase/ssr'
import type { Handle } from '@sveltejs/kit'

export const handle: Handle = async ({ event, resolve }) => {
  event.locals.supabase = createServerClient(PUBLIC_SUPABASE_URL, PUBLIC_SUPABASE_ANON_KEY, {
    cookies: {
      getAll() {
        return event.cookies.getAll()
      },
      setAll(cookiesToSet, headers) {
        // 1. Let SvelteKit's native cookie manager write auth data securely
        cookiesToSet.forEach(({ name, value, options }) =>
          event.cookies.set(name, value, { ...options, path: '/' })
        )

        // 2. Loop and apply the anti-CDN headers individually inside a protective block
        if (headers && Object.keys(headers).length > 0) {
          for (const [key, value] of Object.entries(headers)) {
            try {
              event.setHeaders({ [key]: value })
            } catch (error) {
              // Prevents SvelteKit from crashing on repetitive validation rounds
              // console.debug(`SvelteKit skipped redundant assignment for header: "${key}"`)
            }
          }
        }
      },
    },
  })

  return resolve(event, {
    filterSerializedResponseHeaders(name) {
      return name === 'content-range' || name === 'x-supabase-api-version'
    },
  })
}

[dhruvxvaishnav]

Hi, I’d like to work on this. I traced the error to multiple PKCE cookie writes calling setAll with the same cache-prevention headers during a single request.

My proposed fix is to keep every cookie-write batch intact while making the cache-prevention headers idempotent for the lifetime of a request-scoped server client. I would also add a regression test using a strict SvelteKit-style callback that rejects setting the same header more than once.

Would this direction fit the intended API?

[mandarini]

Hi @decasdev, thank you for opening this issue! I dug into this and can confirm the bug, your root cause analysis is right.

signInWithOtp() writes three PKCE-related storage keys in sequence (the per-flow verifier slot, the flow index, and a legacy fixed key), and our server storage adapter applies each of those writes to cookies immediately since there's no auth state event to hook into for PKCE storage. That means setAll fires three times per signInWithOtp() call instead of once, each carrying the cache-prevention headers from #176. Most frameworks silently overwrite a repeated header set, so this has been happening quietly everywhere. SvelteKit is just strict about it and throws. In the meantime, the workaround from the thread is a solid stopgap: wrap event.setHeaders() in a try/catch per header in your setAll, since the header value is identical every time so dropping the redundant ones loses nothing.

@dhruvxvaishnav your proposed direction is the right one. The headers are a fixed constant, so making them idempotent for the life of a request-scoped client just means sending them once and passing an empty object on later setAll calls from that same instance. The multiple cookie writes themselves are fine as is, only the repeated header is the problem. A regression test with a strict setAll callback like the SvelteKit one here would be a great addition alongside the fix.

Thanks again for the detailed writeup, it made this easy to trace.

[dhruvxvaishnav]

Thanks for confirming the root cause and approach. Since you assigned the issue to yourself, I just wanted to clarify: would you like me to proceed with implementing the fix and regression test, or are you planning to handle the implementation?

[mandarini]

Yes, proceed with implementation @dhruvxvaishnav !