Latest Results
fix(astro): merge new response cookies into original AstroCookies for error pages
When Astro renders a custom error page (404.astro / 500.astro), any
cookies set on the error page via Astro.cookies.set() never reached
the final response. If the original page also set a cookie, the error
page's cookies vanished entirely.
Root cause in mergeResponses:
- The merged response's headers were built by appending every header
from originalResponse.headers (including any set-cookie entries)
into a fresh newHeaders Headers object, then skipping any header
name from newResponse.headers that was already in the seen set.
set-cookie matches that seen set the moment the original response
contributed its own set-cookie entries, so newResponse's set-cookie
entries were silently dropped.
- The new cookies were appended to originalResponse.headers via
originalResponse.headers.append('set-cookie', cookieValue), but the
merged response was built from newHeaders, which is a separate
Headers object copied from the originals before the append. The
append went to a Headers object no one else held a reference to.
Repro from #17329: 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=/"]
Fix: when both responses carry an AstroCookies instance, call
originalCookies.merge(newCookies) to fold the new entries into the
original AstroCookies object, then attachCookiesToResponse below
emits the combined set on the merged response. Appending to
originalResponse.headers is removed because it never reached the
merged response.
Behavior is unchanged when only one response carries cookies.
Closes #17329sanjibani:fix/issue-17329-error-page-cookies Latest Branches
0%
sanjibani:fix/issue-17329-error-page-cookies 0%
feat/data-store-backend-abstraction -1%
© 2026 CodSpeed Technology