new Date() problem with cacheComponents on AWS Lambda

When Next.js is deployed to AWS Lambda, console.* methods calls are leading to https://nextjs.org/docs/messages/next-prerender-current-time errors due to AWS Lambda runtime patching console.* methods to inject timestamps (using new Date() internally for that).

This is "reproduction" of the problem by somewhat mimicking AWS Lambda runtime console patching in patch-console.mjs file.

Steps:

1. Install, build and start the app:

   npm i
   npm run build
   npm run start
   # start script injects console patching: "NODE_OPTIONS='--import ./patch-console.mjs' next start"

2. Visit or curl http://localhost:3000/novel/server

3. Observe 500 error and next start logs:

   • A non-fatal warning is being logged with console.error (this is specific to this concrete reproduction, but any log would result in the same problem):

     [2025-09-12T13:34:01.133Z] A Cache Function (`use cache`) was passed to startActiveSpan which means it will receive a Span argument with a possibly random ID on every invocation leading to cache misses. Provide a wrapping function around the Cache Function that does not forward the Span argument to avoid this issue.
     

   • Because console patching make use of new Date(), logging above warning results in new Date() bailout and fatal/500 error:

     [2025-09-12T13:34:02.181Z] Error: Route "/[slug]/server" used `new Date()` before accessing either uncached data (e.g. `fetch()`) or Request data (e.g. `cookies()`, `headers()`, `connection()`, and `searchParams`). Accessing the current time in a Server Component requires reading one of these data sources first. Alternatively, consider moving this expression into a Client Component or Cache Component. See more info here: https://nextjs.org/docs/messages/next-prerender-current-time
         at console.<computed> [as error] (patch-console.mjs:7:18)
         at <unknown> (.next/server/app/[slug]/fallback/page.js:1:946)
         at a (.next/server/app/[slug]/fallback/page.js:1:2327)
     [2025-09-12T13:34:02.184Z] To get a more detailed stack trace and pinpoint the issue, try one of the following:
       - Start the app in development mode by running `next dev`, then open "/[slug]/server" in your browser to investigate the error.
       - Rerun the production build with `next build --debug-prerender` to generate better stack traces.
     [2025-09-12T13:34:02.185Z] Error:
         at async o (.next/server/app/[slug]/server/page.js:1:11119) {
       code: 'NEXT_STATIC_GEN_BAILOUT'
     }
     

I know I could make this repro work by using performance and not Date in patch-console.mjs (as per notes in https://nextjs.org/docs/messages/next-prerender-current-time) but this is just mimicking AWS Lambda runtime, so it's very intentional to use Date there.

I do understand why you'd want to track cases of Date usage for Cache Components, but if handling of new Date() etc stays as-is in Next.js - this will be a problem that would need to be handled not just with deployments on Netlify, but also other deployments that might use AWS Lambda and potentially other cloud providers that might do patching of console.* methods (or anything else really that would use new Date() etc internally that is not at all related to Next.js app rendering).

It's probable that there is a way to work around this interaction, but:

1. would need to be replicated in all deployments that might use AWS Lambda (or others that might do similar patching),
2. this has potential to happen in other cases that is not possible to foresee (both today or just randomly in future if some runtime implementation changes).

Ideally the tracking of Date is somehow scoped to Next.js code itself and not leak to global Date that might be used outside of Next.js app logic.

---

This test site is pretty much copy of https://github.com/vercel/next.js/tree/b1e2dc2ad52e0447aad9d567074b1ceb56368e4c/test/e2e/app-dir/cache-components-allow-otel-spans test fixture just with mimicking of console.* patching of AWS Lambda runtime (problem was discovered when debugging one of tests in that test suite failing when deploying to Netlify).