`Date` usage tracking is leaking too much outside of Next.js rendering

[pieh]

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 git@github.com: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 opennextjs/opennextjs-netlify@57d4b57#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)

[gnoff]

Hi @pieh thanks for reporting.

I think the answer to this particular problem is more patching actually. The problem with most new Date() access is we have no way of knowing whether it'll be used to determine logical computation or show up in rendered output or if it's ancillary metadata used for logging / telemetry only. Right now we err on the side of correctness where we enforce purity of the prerender (exclude anything non-deterministic unless explicitly cached). But just like with otel we have a special out here.

When a console message is being prepared internally we know how any new Date() is going to be used. This is because the API itself conveys it's intent and conveniently it doesn't return the value and so there is not practical way, nor common practice to get anything out of the call. So what I think we will do is patch the console methods to escape the prerender scope. Unlike most of our patches though this one ought to run as late as possible since any other patching ought to be done first. In fact we should probably only patch it for the duration of the prerender.

As for custom libraries it'd be much harder to find yourself in this position b/c if you are doing any sort of logging in your project in dev you will hopefully be triggering the code patheways there. One reason this issue isn't showing up at build time is that the console isn't patched there but presumably with winston it'd be consistent in all environments. Another reason is there are no logs directly in user code but it happens that an unrelated log which is next start only is triggering the failure during a prerender when the server is running. You can't trigger winston indirectly like this unless you patch the native console methods to forward the logs. As an aside it's kinda odd that we don't run instrumentation in next build. We're thinking of changing that. The otel warning should ideally happen in builds too, but that's an aside.

[gnoff]

will be fixed by: #83843

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.