[Bug?]: Cookies set before redirect are not read on the page you end up on with single-flight-mutations

[jakst]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Current behavior 😯

When setting a cookie and redirecting the user to a new page, you cannot read that cookie value on the page you are redirected to when single-flight-mutations are enabled (i.e. by default).

Expected behavior 🤔

I would expect single-flight-mutation to be indistinguishable from regular redirects, so the cookie can be read on the new page.

Steps to reproduce 🕹

Steps:

1. Check out this repo https://github.com/jakst/solid-cookie-sfm
2. Launch the dev server and visit the app
3. Click the login button
   1. Notice you werent logged in.
   2. Notice the cookie has been set in browser developer tools
4. Click the login button again
   1. Now you are logged in

Context 🔦

I want to implement a fairly simple cookie based auth, and so I need to set an auth cookie in the login action and then read it on all other pages to verify the user is authenticated.

Your environment 🌎

System:
  OS: macOS 15.2
  CPU: (12) arm64 Apple M3 Pro
  Memory: 700.55 MB / 36.00 GB
  Shell: 5.9 - /bin/zsh
npmPackages:
  @solidjs/router: 0.15.2 => 0.15.2 
  @solidjs/start: 1.0.10 => 1.0.10 
  @types/node: 22.10.2 => 22.10.2 
  solid-js: 1.9.3 => 1.9.3 
  tinybase: ^5.4.4 => 5.4.4 
  typescript: 5.7.2 => 5.7.2 
  vinxi: 0.5.1 => 0.5.1

[zhengkyl]

I ran into this same problem, and I found a hacky workaround by digging into h3 internals. In the same place where I set the Set-Cookie header, I add the cookie to the current request like this.

getRequestEvent()!.nativeEvent.node.req.headers.cookie = `key=${value}`;

That's because the transpiled code for getCookie looks like this.

function parseCookies(event) {
  return parse$1(event.node.req.headers.cookie || "");
}
function getCookie(event, name) {
  return parseCookies(event)[name];
}

I'd love to know if there is a better way, or if the approach has issues, but I'm handling protected routes exactly like in the reproduction repo, and this seems to work for now.