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.

[icyJoseph]

is there any source code to look at? - I wonder if it happens between deploys or something like that?

[ellemedit]

In my case, it was observed since Next.js 16 upgraded. I have same condtions. 16.0.8, custom cache handler, sentry, cache components, standalone mode. I think both build and runtime cause this error.

[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