Open mrthinger opened 2 weeks ago
it looks like they introduced a cache for hot reloads thats on by default.
disabling this fixes the issue.
https://nextjs.org/docs/app/api-reference/next-config-js/serverComponentsHmrCache
Thanks for the detailed report, Evan.
This looks to be a similar issue that Svelte used to have, where universal load functions would fail to serialize pre-fetched requests with a non-JSON request body: https://github.com/sveltejs/kit/issues/8302
From a quick glance, generateCacheKey
really doesn't handle Uint8Array at all. It does handle readable streams and blobs (both can hold arbitrary binary data), but interprets them as UTF-8 text, serializes them to a JSON string, then UTF-8 encodes that string to bytes, and passes them to a hash function 🤔
I'm not sure this is intended behavior. It seems reasonable to me to support simple binary request bodies in generateCacheKey
. Could you create an issue in the next.js repository?
Could you create an issue in the next.js repository?
Yes and I appreciate your considerate response. I'll see to it sometime tomorrow.
When calling a unary method using @connectrpc/connect-web in a React server component in Next.js 15, you will always get the following error:
Failed to generate cache key for https://demo.connectrpc.com/connectrpc.eliza.v1.ElizaService/Say
Example: https://github.com/connectrpc/examples-es/blob/938b4cbd7050bd2e7f73f31ccc89dabfc3443e3b/nextjs/app/react-server-actions/page.tsx#L22
To Reproduce node 22
Once the server is running:
Additional context Error seems to be from: https://github.com/vercel/next.js/blob/v15.0.2/packages/next/src/server/lib/patch-fetch.ts#L536
The source of the issue appears to be that the cache key computation doesn't account for the fetch body being a Uint8Array: https://github.com/vercel/next.js/blob/v15.0.2/packages/next/src/server/lib/incremental-cache/index.ts#L265
I don't know why Next14 didn't have this issue but 15 does. I thought POST fetches are still supposed to bypass cache completely?