Refreshing a session when you have created multiple serverClients for a request results in duplicate Set-Cookie headers, can blow out header limits on CF

[mike-littlechapter]

essentially the title.

During an SSR request, createServerClient might be called in the auth loader, and again later in some server function or internal api.

when the client refreshes an expired session using the refresh token and calls setAllCookies to set the Set-Cookie header, there is shared state between all the current server clients, and they all add these Set-Cookie headers, leading to duplicate Set-Cookie headers for large session objects

This can rapidly blow out the response header limits of cloudfront leading to 502's when there are multiple server clients

Expected behaviour:

Only the client used to call auth.refreshSession() should call the setAllCookies method to set Set-Coookie headers with the updated session

[AmritanshuPatra85]

Hi, I dug into the source to understand the root cause and wanted to share my findings before opening a PR.
Root cause: Each createServerClient call creates its own isolated setItems/removedItems objects inside createStorageFromOptions. When a token refresh happens, GoTrue independently populates each client's setItems by reading from the same underlying cookie store. This means all clients end up with identical session data in their setItems, and when TOKEN_REFRESHED fires, every client's onAuthStateChange handler sees hasStorageChanges = true and calls applyServerStorage — which calls the user-provided setAll once per client, producing duplicate Set-Cookie headers.
Proposed fix: Wrap setAll inside createStorageFromOptions (server path only) with a fingerprint-based deduplication layer before returning it. The fingerprint is the full name=value string of the cookie payload. If an identical payload has already been written in this request cycle, the wrapper is a no-op. Different payloads (e.g. a SIGNED_OUT after a TOKEN_REFRESHED) still go through normally.
This is ~12 lines of change confined to cookies.ts. No API surface changes, no breaking changes.
Happy to open a PR if this approach looks reasonable to you — wanted to get alignment on the direction first.