Skip to content

fix(client-engine-runtime): make NowGenerator lazy to avoid synchronous new Date() calls#28724

Merged
jacek-prisma merged 2 commits into
prisma:mainfrom
Priyank-Gaur:fix/issue-28588-lazy-now-generator
Mar 16, 2026
Merged

fix(client-engine-runtime): make NowGenerator lazy to avoid synchronous new Date() calls#28724
jacek-prisma merged 2 commits into
prisma:mainfrom
Priyank-Gaur:fix/issue-28588-lazy-now-generator

Conversation

@Priyank-Gaur
Copy link
Copy Markdown
Contributor

@Priyank-Gaur Priyank-Gaur commented Nov 25, 2025

The Issue: The GeneratorRegistry.snapshot() method creates a snapshot of all generators, including NowGenerator

class NowGenerator implements ValueGenerator {
  #now: Date = new Date()

  generate(): string {
    return this.#now.toISOString()
  }
}

The NowGenerator was initializing new Date() in its property declaration, meaning it was called synchronously during every query preparation, even if now() was not used.

The Fix: I modified NowGenerator to be lazy.

class NowGenerator implements ValueGenerator {
  #now: Date | undefined

  generate(): string {
    if (this.#now === undefined) {
      this.#now = new Date()
    }
    return this.#now.toISOString()
  }
}

The #now field is now initialized as undefined, and new Date() is only called inside the generate()

class NanoIdGenerator implements ValueGenerator {
  generate(arg: unknown): string {
    if (typeof arg === 'number') {
      return nanoid(arg)
    } else if (arg === undefined) {
      return nanoid()
    } else {
      throw new Error('Invalid Nanoid generator arguments')
    }
  }
}

method if it hasn't been initialized yet.

Fixes #28588

@Priyank-Gaur
fix(client-engine-runtime): make NowGenerator lazy
7f69e4d 
This commit changes NowGenerator to lazily initialize the date only when generate() is called.
Previously, GeneratorRegistry.snapshot() would create a NowGenerator which synchronously called new Date().
This caused Next.js dynamic usage errors ('used new Date() before accessing either uncached data') even when now() was not used in the query.

Fixes prisma#28588
@CLAassistant
Copy link
Copy Markdown

CLAassistant commented Nov 25, 2025 •
edited
Loading

CLA assistant check
All committers have signed the CLA.

@Priyank-Gaur Priyank-Gaur changed the title This PR fixes an issue where Prisma 7 triggers Next.js dynamic usage errors in cached components. fix(client-engine-runtime): make NowGenerator lazy to avoid synchronous new Date() calls Nov 25, 2025
@aqrln
Copy link
Copy Markdown
Member

aqrln commented Nov 27, 2025

I'm not opposed to this, but I'm not sure it will have any measurable impact to be honest. Is this a theoretical concern or an actual issue you profiled?

Also, if you'd like to get this merged, please sign the CLA.

@Priyank-Gaur
Copy link
Copy Markdown
Contributor Author

Priyank-Gaur commented Nov 27, 2025

I'm not opposed to this, but I'm not sure it will have any measurable impact to be honest. Is this a theoretical concern or an actual issue you profiled?

Also, if you'd like to get this merged, please sign the CLA.

Thank you for telling me to sign the CLA, This is my first time contributing to a big repository so I didn't knew that.
And about the issue I saw it from existing issues.
When using Prisma 7 together with Next.js Cache/Server Components, the eager new Date() call inside NowGenerator was being executed during generator snapshot creation. That triggers Next.js’ runtime warning:

“used new Date() before accessing either uncached data”

This happens even when now() is not used in the query.
By deferring the date initialization to the generate() method, the warning disappears and the page renders correctly without requiring additional workarounds.
So the change does have a measurable effect in real applications — it prevents premature time access during static evaluation.
If there is anything else you'd like to ask feel free.....it will help me to learn more.....Thanks

@ftognetto
Copy link
Copy Markdown

ftognetto commented Dec 24, 2025

I'm not opposed to this, but I'm not sure it will have any measurable impact to be honest. Is this a theoretical concern or an actual issue you profiled?

Also, if you'd like to get this merged, please sign the CLA.

This is blocking all the Nextjs builds, for example. #28588

@damischa1
Copy link
Copy Markdown

damischa1 commented Dec 31, 2025

In our case prevents building the NextJS app. Any page that is making prisma queries is not possible to cache with cacheComponents. And actually those are the pages that we want to use caching. So the measurable impact is big.

@mugiwaraya
Copy link
Copy Markdown

mugiwaraya commented Mar 16, 2026

Any news follow-up on this?

@cipriancaba
Copy link
Copy Markdown

cipriancaba commented Mar 16, 2026

This is why people move to @drizzle

@jacek-prisma jacek-prisma merged commit 3f2438c into prisma:main Mar 16, 2026
250 of 252 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

1 more reviewer

@jacek-prisma jacek-prisma jacek-prisma approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Prisma 7 + Nextjs + CacheComponents: "used new Date() before accessing either uncached data"

8 participants

@Priyank-Gaur @CLAassistant @aqrln @ftognetto @damischa1 @mugiwaraya @cipriancaba @jacek-prisma