Link to the code that reproduces this issue

https://github.com/pieh/next-cache-components-timestamped-console-methods

To Reproduce

The reproduction loosely mimics console.* patching that is done by AWS Lambda Node Runtime where any of methods will get timestamp via new Date().

1. Install, build and start the app:

   git clone [email protected]:pieh/next-cache-components-timestamped-console-methods.git
   cd next-cache-components-timestamped-console-methods
   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

Current vs. Expected behavior

Current:

Accessing http://localhost:3000/novel/server result in 500 error, due to:

• 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'
  }

Expected:

Usage of Date outside of Next.js rendering itself should not cause prerender bailout. Ideally global Date is not patched at all and maybe instead this could be scoped to Next app code itself during bundling if that is viable?

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:30 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6020
  Available memory (MB): 32768
  Available CPU cores: 12
Binaries:
  Node: 20.19.0
  npm: 10.8.2
  Yarn: N/A
  pnpm: 8.15.8
Relevant Packages:
  next: 15.6.0-canary.6 // Latest available version is detected (15.6.0-canary.6).
  eslint-config-next: N/A
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.9.2
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

cacheComponents

Which stage(s) are affected? (Select all that apply)

next start (local)

Additional context

There is workaround possible for this specific case by doing another console.* patch and temporarily restore global Date to its original, unpatched version -> call original console method -> restore patched Date again, but fact that it needs to be done is bad signal, because it indicate there is possibility of not yet known cases that might need similar workaround. For reference - this is a workaround that works for problems discovered so far https://github.com/opennextjs/opennextjs-netlify/commit/57d4b572abaa65f5a53a20e77ac75d85c2d5c9aa#diff-dcf9b6fe3dc0a3eaf360c9f67687ba91e75a41007e4e25a596edcfda5ed83d77R39-R62

Other than AWS Lambda Node Runtime specific interaction - another very similar case that comes to mind would be if someone would use some logging solution - like winston lib with its timestamp feature (but this one seems difficult to support without getting rid of heuristic completely, because this would become part of application code, so only workaround here is to not use timestamp feature, change logging library or attempt to adjust implementation of logging library).

Overall, it feels like the Date usage prerender bailout heuristic is leaking too much and will be ongoing source of issues with both deployment platform's internal usage of Date (something deployment targets will need to workaround) as well as 3rd party dependencies (users will be facing frustrations and will need to workaround/replace dependency/request implementation changes to move of new Date() to performance)