Stale request.cookies value if updated in middleware without explicitly passing new headers to NextResponse

[boreyko1]

Link to the code that reproduces this issue

https://github.com/boreyko1/next-stale-cookie-middleware-repro

To Reproduce

1. next dev
2. visit the page and check server logs

Current vs. Expected behavior

Setting or updating a cookie value in the middleware does not make it updated further down in the request i.e. using in page server components.

Logs from the repro describing the issue:

-------- // first clean request
[middleware] incoming value undefined
[middleware] updated value 1698471447770
[middleware] check request cookie 1698471447770
[middleware] check response cookie 1698471447770
[page server component] value undefined
-------- // second request
[middleware] incoming value 1698471447770
[middleware] updated value 1698471474936
[middleware] check request cookie 1698471474936
[middleware] check response cookie 1698471474936
[page server component] value 1698471447770

You can see above that [page server component] is not updated with the new value from the middleware even though request.cookies.get('test').value returns an updated one. Basically it lags one Set-Cookie response behind in that case.

I managed to get the expected behavior by manually passing { headers: new Headers(request.headers) } on NextResponse.next() init. But this is not that obvious one needs to explicitly reference request.headers in the response.headers in order for it to work properly in the current ongoing request.

Logs after the workaround and expected behavior:

-------- // first clean request
[middleware] incoming value undefined
[middleware] updated value 1698471924699
[middleware] check request cookie 1698471924699
[middleware] check response cookie 1698471924699
[page server component] value 1698471924699
-------- // second request
[middleware] incoming value 1698471924699
[middleware] updated value 1698471927901
[middleware] check request cookie 1698471927901
[middleware] check response cookie 1698471927901
[page server component] value 1698471927901

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.0.0: Fri Sep 15 14:41:43 PDT 2023; root:xnu-10002.1.13~1/RELEASE_ARM64_T6000
Binaries:
  Node: 20.8.1
  npm: 9.6.4
  Yarn: 3.3.1
  pnpm: 7.9.0
Relevant Packages:
  next: 14.0.1-canary.1
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

App Router, Middleware / Edge (API routes, runtime)

Additional context

I reproduced this issue with next 13, next 14 and 14.0.1-canary.1. Even though a possible userland workaround is described above I still do not think it is an expected behavior. Docs also do not mention anything like that in the Using Cookies section for the middleware.

Let me know if I can help somehow or it is not an issue at all. If so, I can probably make a docs PR then.
Thanks!

[boreyko1]

tried 14.0.3-canary.11 – the issue is still there

[boreyko1]

14.0.5-canary.23 still the same

[XEngine]

I am also having the same issue. I think updating cookies inside middleware should update the server component's cookies() function while in the same request. It's because middleware runs in the edge runtime only maybe?

[LouisJackson]

I have the same issue adding cookies after creating the response and before sending it.

const requestHeaders = new Headers(request.headers);
const response = NextResponse.rewrite(
		new URL(
			`/foo`,
			request.url,
		),
		{
			request: { headers: requestHeaders },
		},
);
response.cookies.set({
  name: 'redirect',
  value: 'true',
  domain: cookieDomain,
});
return globalResponse;

[kubmir]

Any solution here ? I am facing the same issue regarding cookies when I want to do redirect in the middleware.

[Talent30]

@leerob @shuding Could you have a look at this please?

[controversial]

Duplicate of #49442

[boreyko1]

Duplicate of #49442

thanks, closing mine then

workaround described in this issue works and aligns with solutions in #49442 if anyone follows this issue, though

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.