Next.js standalone deployment prefetch response 500

[ellemedit]

Summary

TypeError: q.segmentData.get is not a function
at p (.next/server/chunks/ssr/_ce606ad6._.js:3:4695)
at async L (.next/server/chunks/ssr/_ce606ad6._.js:3:7928)

In production, prefetch request cause above error.

next.js/packages/next/src/build/templates/app-page.ts

Line 1126 in 24ccec0

const matchedSegment = cachedData.segmentData.get(segmentPrefetchHeader)

is suspicious.

Additional information

No response

Example

No response

[ezeparziale]

I am getting the same error with 16.0.8 and custom cache-handler.mjs in standalone mode.

[ezeparziale]

I realized that cacheHandler can’t be used when cacheComponents: true is enabled. In that case, you need to use cacheHandlers instead, defining both the default handler and the remote one.

What I’m not fully sure about now is whether both approaches can be used together or what the recommended pattern is, especially when running the cache on a self-hosted Redis instance.

Also, when using cacheHandlers with a custom default handler, it seems that revalidatePath no longer works. It looks like only updateTag works, because revalidatePath expects the N_T/page tag to exist — and that tag is not stored when using cacheHandlers.

References:

https://nextjs.org/docs/app/api-reference/config/next-config-js/incrementalCacheHandlerPath

https://nextjs.org/docs/app/api-reference/config/next-config-js/cacheHandlers

[icyJoseph]

Gotta update the docs, surprised I missed updating that these are mutually exclusive.

Yeah, so for soft tags (the implicit route tags like _N_T_/products that come from revalidatePath), there are two ways to handle them:

• Your getExpiration(tags) returns the timestamp when those tags were invalidated, and Next.js compares it against the cache entry's timestamp.

• or, you return Infinity from getExpiration, which means the above check is skipped, and then in your get(cacheKey, softTags) method, you check that second softTags argument against your store to see if any were invalidated after the entry was created.

For both approaches the updateTags method should somehow store the tags it receives w/ an invalidation timestamp (both hard tags from revalidateTag and soft tags from revalidatePath).

• Here's a community implementation: https://github.com/mrjasonroy/cache-components-cache-handler/blob/main/packages/cache-handler/src/data-cache/memory.ts that uses a global Map to store cache tag invalidation info.

[ellemedit]

thank you. wish these to be into docs.

[ezeparziale]

Thanks! I just tested this custom handler and everything works correctly with "use cache" functions and revalidatePath when cacheComponents: true is enabled.

I also updated my Kubernetes template to use this handler along with Next.js 16, in case it’s useful for anyone:

https://github.com/ezeparziale/nextjs-k8s

[icyJoseph]

@ellemedit could you sketch how did you end up triggering this issue? Trying to write docs but also wondering if this should be caught at build time in some fashion, so I want to be able to trigger this issue myself.

[icyJoseph]

It's time to drop an update here.

There has been some confusion for cacheHandler and cacheHandlers usage. One thing we should state clearly is that you can use both.

In the case of OP here, the problem is serialization. As this issue points out: mrjasonroy/cache-components-cache-handler#29

Next.js 16 stores segmentData as a Map<string, Buffer> and rscData as a Buffer on APP_PAGE cache entries. Plain JSON.stringify converts Maps to {} and loses Buffer identity, so on deserialization segmentData.get() throws

And the solution, as the PR also points out, is to fix the serialization (and deserialization).

Adds custom jsonReplacer/jsonReviver to the Redis ISR handler that preserve Map and Buffer types through the serialization round-trip

[icyJoseph]

@ellemedit do you think you can update the selected answer?