Cookies modified then read back again in an RSC return unmodified values

next@v15.0.0-canary.160 unskipped some tests in this commit These tests hadn't been running for some time.

Many of these tests fail on Netlify. For example:

  ● app-dir with middleware › should be possible to modify cookies & read them in an RSC in a single request

    expect(received).toMatch(expected)

    Expected pattern: /Cookie 1: \d+\.\d+/
    Received string:  "Cookie 1:"

      132 |
      133 |     // cookies were set in middleware, assert they are present and match the Math.random() pattern
    > 134 |     expect(initialRandom1).toMatch(/Cookie 1: \d+\.\d+/)
          |                            ^
      135 |     expect(initialRandom2).toMatch(/Cookie 2: \d+\.\d+/)
      136 |     expect(totalCookies).toBe('Total Cookie Length: 2')
      137 |

      at Object.toMatch (e2e/app-dir/app-middleware/app-middleware.test.ts:134:28)

If you run the fixture locally, it appears to work as expected with next dev, ntl dev, and ntl serve, but it does not work as expected when deployed to Netlify (more detail below).

These tests and fix for the issue being tested were originally introduced in next.js in https://github.com/vercel/next.js/pull/65008. My guess is they wouldn't have passed at the time on Netlify. Deploying the fixture exhibits the same behaviour with older canary versions and with next@latest.

I believe this is possibly a confusing intersection of three unrelated things:

there is an inherent flakiness in these tests causing cookie 1 to get unset: https://github.com/vercel/next.js/pull/71319
the above is only triggering because of https://linear.app/netlify/issue/FRB-1359/nextjs-prefetch-priority-tests-are-failing (assuming that is a real issue as opposed to a simple test setup issue)
what https://github.com/vercel/next.js/pull/65008 was intending to fix is not fixed on Netlify, presumably due to something in next-runtime

This is largely conjecture, but what I observe is that when reloading the fixture page repeatedly I sometimes see both cookies set on the page and on the response, sometimes one is missing on the page but not headers, and sometimes they are missing on both. It's nondeterministic and confusing. However, if I remove the <Link href="/rsc-cookies-delete"> (or add prefetch={false}), the behaviour is much simpler: the two cookies are always set on the response but the values on the page always reflect the previous values; e.g.

load 1:
  headers: 4 5
  page: [blank] [blank]
load 2:
  headers 6 7
  page: 4 5
load 3:
  headers 8 9
 page 6 7

which is what led me to the above conclusions. This is the same on next@latest and next@canary.

I have no idea why this cannot be reproduced locally. It might be timing related?

You can verify the above with this repo (which is mostly just a copy of the test fixture): https://github.com/serhalp/nextjs-canary-rsc-cookies-repro.

This has never been reported by users AFAIK.

Data

The following is parsed automatically by the Next.js repo e2e test report generator.

test: test/e2e/app-dir/app-middleware/app-middleware.test.ts reason: Cookies modified then read back again in an RSC return unmodified values

opennextjs / opennextjs-netlify

Cookies modified then read back again in an RSC return unmodified values #2669

Data