[start] Duplicate Set-Cookie headers dropped on Linux (Bun) for 2xx Response returns

[awinogradov]

Describe the bug

When a TanStack Start API route returns a Response that contains two Set-Cookie headers, only one of them reaches the client on Linux + Bun. The same code works correctly on macOS + Bun (same Bun version, same package versions).

Observed while wiring BetterAuth into a TanStack Start app: BetterAuth sets better-auth.session_token and better-auth.session_data on a successful sign-in. On GitHub Actions (ubuntu-latest, Bun 1.3.9) only session_data survives to the browser. On macOS (Bun 1.3.9) both survive.

Your Example Website or App

Minimal reproduction route (drops an extra route into any TanStack Start app scaffold):

// src/routes/api/cookies.ts
import { createFileRoute } from "@tanstack/react-router";

export const Route = createFileRoute("/api/cookies")({
  server: {
    handlers: {
      POST: async () => {
        const headers = new Headers();
        headers.append("set-cookie", "a=1; Path=/; HttpOnly; SameSite=Lax");
        headers.append("set-cookie", "b=2; Path=/; HttpOnly; SameSite=Lax");
        return new Response(JSON.stringify({ ok: true }), { status: 200, headers });
      },
    },
  },
});

Hit it from both environments:

curl -i -X POST http://localhost:3001/api/cookies

I can stand up a full minimal-repro repo if it would help — just wanted to file the observation first.

Steps to Reproduce the Bug or Issue

1. Scaffold a TanStack Start app (React).
2. Add the route above.
3. Run bun run dev on macOS. Curl the route — the response carries two Set-Cookie headers.
4. Run the same code on a GitHub Actions ubuntu-latest runner (or any Linux + Bun 1.3.9). Curl the route — the response carries one Set-Cookie header (b=2). Cookie a is silently dropped.

Expected behavior

Both Set-Cookie values should reach the client, regardless of OS/runtime. This is critical for any auth library that sets both an opaque session token and a signed session-data cache in the same response (BetterAuth is one such case; see better-auth/better-auth).

Additional context

• Affected versions (from bun.lock): @tanstack/react-start@1.167.34, @tanstack/react-start-server@1.166.37, @tanstack/start-server-core@1.167.18, h3@2.0.1-rc.20, bun@1.3.9, vite@8.0.8.
• I verified via a debug response header (x-auth-debug-cookies) set from inside the route handler that response.headers.getSetCookie().length === 2 at the moment the handler returns — so the drop happens after the route handler returns, somewhere between TanStack Start's prepareResponse / h3_toResponse and the wire.
• Explicitly rebuilding the Response with headers.getSetCookie() + headers.append("set-cookie", …) in the route handler does not fix it on Linux. Both values are in the returned Headers object; one still gets dropped.
• Removing all h3 event-header writers (i.e. not using anything that calls setCookie from @tanstack/react-start/server) also does not fix it on Linux, so the prepareResponse → mergeHeaders$1 path that merges preparedHeaders into val.headers is not the culprit on its own.
• The suspect lines I looked at: @tanstack/start-server-core/src/request-response.ts — mergeEventResponseHeaders early-returns on response.ok, and mergeHeaders$1 in h3@2.0.1-rc.20/dist/h3-*.mjs uses target.set(name, value) for non–set-cookie headers which would preserve duplicates, but I did not prove this is where the drop happens.
• Workaround used in our codebase: disable BetterAuth's cookieCache so only a single session_token cookie is emitted. Confirms the drop is specific to duplicate Set-Cookie entries, not specific to any cookie name or value.

Happy to iterate on a minimal-repro repo or capture a trace if that speeds up triage.

[schiller-manuel]

please provide a complete minimal reproducer project. does this also fail with node?

[awinogradov]

Here's a standalone, runnable reproduction with a matrix CI that shows the platform split:

https://github.com/awinogradov/reproduce-tanstack-router-cookie-issue

What it does

• src/routes/api/cookies.ts — a single POST handler that builds a fresh Headers object, appends two Set-Cookie values (a=1; … and b=2; …), and returns a 200 Response. It also sets an x-debug-cookies header with headers.getSetCookie().length at the moment of return, so you can see what the handler emitted vs what the client received.
• scripts/repro.ts — boots the TanStack Start dev server via bun run dev, waits for http://localhost:3001/ to respond, POSTs to /api/cookies, and exits 0 if response.headers.getSetCookie().length === 2 or 1 otherwise.
• .github/workflows/repro.yml — runs the script on both ubuntu-latest and macos-latest GitHub runners with Bun 1.3.9.

First CI run

First push, no tweaks: run #24428746631 — macos-latest ✅, ubuntu-latest ❌, 17s total.

ubuntu-latest output:

[repro] status: 200
[repro] x-debug-cookies (set by the handler): 2
[repro] client-visible set-cookie count:       1
[repro]   [0] b=2; Path=/; HttpOnly; SameSite=Lax
[repro] FAIL — handler set 2 cookies, client saw 1 on linux/x64 bun=1.3.9

macos-latest output:

[repro] status: 200
[repro] x-debug-cookies (set by the handler): 2
[repro] client-visible set-cookie count:       2
[repro]   [0] a=1; Path=/; HttpOnly; SameSite=Lax
[repro]   [1] b=2; Path=/; HttpOnly; SameSite=Lax
[repro] PASS — both cookies reached the client on darwin/arm64 bun=1.3.9

Identical source, identical dependency tree (bun.lock committed), identical Bun version (oven-sh/setup-bun@v2 pinned to 1.3.9) — the only difference between the two jobs is the OS. On Linux, the first Set-Cookie (a=1) is silently dropped; only the second (b=2) reaches the client.

Note the debug header: the handler consistently reports 2 cookies at return time, so the drop happens after the route handler returns, somewhere in the TanStack Start → h3 → Bun HTTP response chain.

Happy to iterate on the repro if it's missing anything.

[awinogradov]

One more clarification since it came up reading the repro — we're not running Node.js anywhere in this reproduction, neither in dev nor in CI:

• The dev server runs via bun run dev → vite dev executed by the Bun runtime.
• The reproduction script runs via bun ./scripts/repro.ts.
• bun install --no-save sets up the dependency tree.
• The GitHub Actions matrix uses oven-sh/setup-bun@v2 and never installs Node.
• Downstream in the project where we first hit this (acclaim-ai/frontend#21), the production image is oven/bun:1-alpine and the runtime command is bun dist/server/server.js — same story.

So whatever is dropping the second Set-Cookie is isolated to the TanStack Start → h3 → Bun HTTP response path on Linux. Node's http module / res.setHeader is not in play, which should help narrow the search.

[awinogradov]

@schiller-manuel, is it helpful enough? If you need anything else, let me know 🙏🏼

[schiller-manuel]

run it with node then. want to rule out a bun issue here

[awinogradov]

@schiller-manuel I don't see the reason.

So whatever is dropping the second Set-Cookie is isolated to the TanStack Start → h3 → Bun HTTP response path on Linux. Node's http module / res.setHeader is not in play, which should help narrow the search.

But if you need help with it, I’m here.

[schiller-manuel]

can you just execute the same test on linux on node instead of using bun?

[awinogradov]

Sorry for the noise on this, @schiller-manuel — I went further on the reproduction and it turns out this is not a TanStack Router / Start issue. You can safely deprioritise or close #7189; I owe you the time you already spent.

What changed since the first comment

I added a nodejs branch to the reproduction repo that runs the exact same TanStack Start app, the same Vite dev server, the same route handler, the same headers.getSetCookie() rebuild — just under Node.js LTS via actions/setup-node@v4 instead of oven-sh/setup-bun@v2. Both branches ship a matrix workflow that runs on ubuntu-latest + macos-latest, and both scripts dump the response in three ways: the x-debug-cookies custom header (what the handler emitted), response.headers.getSetCookie() (what fetch parses), and a raw TCP socket read (what's actually on the wire).

Repro: https://github.com/awinogradov/reproduce-tanstack-router-cookie-issue — main branch is Bun, nodejs branch is Node LTS.

Test matrix

Runtime	Runner	handler emitted	raw TCP wire	fetch().getSetCookie()	result
Bun 1.3.9	macos-latest	2	2	2	✅ PASS
Bun 1.3.9	ubuntu-latest	2	1 (b=2 only)	1 (b=2 only)	❌ FAIL
Node LTS (24.x)	macos-latest	2	2	2	✅ PASS
Node LTS (24.x)	ubuntu-latest	2	2	2	✅ PASS

Run links:

• Bun ubuntu fail — https://github.com/awinogradov/reproduce-tanstack-router-cookie-issue/actions/runs/24430602277
• Node ubuntu pass — https://github.com/awinogradov/reproduce-tanstack-router-cookie-issue/actions/runs/24430979246

Identical source, identical Vite dev server, identical TanStack Start version tree, identical GitHub runner image. The only axis that flips the result is the runtime.

What the raw socket pinned down

When we drop into a plain TCP socket and read the bytes directly off the wire on ubuntu-latest + Bun, the second Set-Cookie is already gone before fetch() ever touches the response. Only the last-appended value (b=2) survives. Every other custom header on the same response (x-debug-cookies, Access-Control-Allow-Origin, Vary, lowercase content-type) passes through unchanged — the drop is specifically Set-Cookie, specifically on duplicate keys. That matches an res.setHeader overwrite pattern, not res.appendHeader.

Under Node LTS on the same ubuntu-latest image, the same TanStack Start / Vite / srvx sendNodeResponse path writes both Set-Cookie lines to the wire correctly. The first link in the chain that changes the answer is nodeRes.writeHead(status, statusText, flatArray) inside srvx/adapters/node.mjs — srvx spreads [...webRes.headers] and .flat()s it into ["set-cookie", "a=1", "set-cookie", "b=2", ...]. Node's http.ServerResponse.writeHead preserves duplicate keys in that flat form; Bun's node:http compat layer on Linux x86_64 does not.

Conclusion

This is a Bun node:http compat bug, not a TanStack Router bug. Neither the prepareResponse merge path in @tanstack/start-server-core, nor the mergeHeaders$1 in h3's toResponse, nor the tanstackStartCookies plugin in better-auth are involved — all three were ruled out earlier by isolating/removing them. TanStack Router is the messenger here via srvx's sendNodeResponse.

I'll file a minimised, framework-free reproduction upstream against oven-sh/bun (bare node:http server + writeHead with a flat array containing two set-cookie pairs) and link it back here when it's open.

Sorry again for taking your time on a false trail. Feel free to close this issue whenever you're comfortable.