Cookies set by a custom 404/500 error page are silently dropped

[tsushanth]

Description

When Astro renders a custom error page (404.astro/500.astro), any cookies that error page sets via Astro.cookies.set() never make it onto the final response. If the original errored page also set a cookie, the error page's cookies vanish entirely.

Root cause

packages/astro/src/core/errors/default-handler.ts (mergeResponses): the merged response's headers (newHeaders) are built by copying originalResponse.headers. Then the error page's cookies are appended to originalResponse.headers — an object already copied and no longer connected to the merged response — and only originalCookies are attached to the merged response, never newCookies. Compounding it, the seen-set guard skips all raw set-cookie values from the error response.

Steps to reproduce

Original page sets sid=abc then throws; 500.astro sets flash=boom.

• Observed final Set-Cookie: ["sid=abc; Path=/"]
• Expected: ["sid=abc; Path=/", "flash=boom; Path=/"]

Suggested fix

originalCookies.merge(newCookies) before attachCookiesToResponse, and/or append cookie values to the merged response's headers (not originalResponse.headers); special-case set-cookie so it bypasses the seen single-winner guard.

[astrobot-houston]

• Reproduced: Yes
• Exploration: Yes — View branch
• Unit Test: Yes — packages/astro/test/error-page-cookies.test.ts
• Priority: P4: important. This silently drops cookies set by custom error pages (404.astro/500.astro), violating the expected behavior of Astro.cookies.set(). Any user relying on cookies in error pages (e.g. flash messages, session tracking) is affected with no warning.

The root cause is in the mergeResponses function in packages/astro/src/core/errors/default-handler.ts. Two bugs: (1) when both the original and error page responses have AstroCookies, newCookies.consume() values were appended to originalResponse.headers — but that object had already been copied into newHeaders and was no longer connected to the merged response, so the values went nowhere; (2) the seen-set guard that deduplicates headers treats set-cookie as a single-value header, blocking any error page set-cookie entries when the original response already had one.

I found a potential fix for this issue. The fix replaces the broken consume()-and-append loop with originalCookies.merge(newCookies) (which correctly merges the outgoing cookie maps), and special-cases set-cookie in the header dedup loop so it always appends rather than being blocked by the seen guard.

Try this fix

You can test this fix right now without waiting for a release:

npm i https://pkg.pr.new/astro@e165373

If this fixes your issue, please leave a comment letting us know (e.g. "confirmed, this fixes it"). We'll then open a pull request to get this merged.

Full Triage Report

Reproduction

Created a test fixture with:

• src/pages/index.astro — sets sid=abc cookie then throws
• src/pages/only-error-cookie.astro — throws without setting cookies
• src/pages/500.astro — sets flash=boom cookie
• src/pages/404.astro — sets not_found=true cookie
• src/middleware.ts — sets sid=abc on every request

Before fix: With addCookieHeader: true, the error page's cookies (flash=boom) were silently dropped. When middleware set cookies and a 404 page also set cookies, only the middleware's cookies survived.

After fix: All three test cases pass — cookies from error pages are correctly preserved, whether used alone or merged with cookies from the original response/middleware.

Diagnosis

File: packages/astro/src/core/errors/default-handler.ts, function mergeResponses

Bug 1 — AstroCookies merge goes to dead end (lines ~248-252):

// BEFORE (broken): appends to originalResponse.headers, which is
// already disconnected from the merged response
for (const cookieValue of newCookies.consume()) {
    originalResponse.headers.append('set-cookie', cookieValue);
}

Bug 2 — seen guard blocks multi-value set-cookie (lines ~226-228):

// BEFORE (broken): set-cookie from error page is skipped because
// originalResponse already contributed a set-cookie entry to `seen`
if (!seen.has(name.toLowerCase())) {
    newHeaders.append(name, value);
}

Fix

Two surgical changes in mergeResponses:

1. Replace the consume()-and-append loop with originalCookies.merge(newCookies) — this uses the existing AstroCookies.merge() method to properly combine cookie maps.
2. Add || lower === 'set-cookie' to the seen guard so raw set-cookie headers from the error response are always appended (they're multi-value headers).

Tests

Added packages/astro/test/error-page-cookies.test.ts with three cases:

1. Error page cookies preserved when original page throws
2. Error page cookies preserved when no original cookies exist
3. Both middleware and 404 error page cookies preserved together

All existing cookie/error tests continue to pass (middleware-app.test.ts cookie tests, custom-fetch-error-pages.test.ts).

This report was made by an LLM. The analysis may be wrong, and the potential fix might not work, but is intended as a starting point for exploring the issue.