`DYNAMIC_SERVER_USAGE` in Next.js App Dir

[EnriqCG]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nextjs

SDK Version

7.74.0

Framework Version

Next.js 13.5.3

Link to Sentry event

https://the-network-state-co-5d0b7f51d.sentry.io/issues/4554179142/?project=4505835380736000&query=is:unresolved&statsPeriod=14d&stream_index=0

SDK Setup

  enableTracing: true,
  tracesSampleRate: 1,
  debug: false,
  replaysOnErrorSampleRate: 1.0,
  replaysSessionSampleRate: 0.1,
  environment: process.env.XX

Steps to Reproduce

1. Set up Sentry for Next.js with the Wizard. Use the server configuration.
2. Insert cookies() or headers() to make a Server Component render dynamically
3. Build the application. No fatal errors that would prevent the build from finishing.

Expected Result

It should not send DYNAMIC_SERVER_USAGE traces that don't prevent the build from succeeding to Sentry.

I think this is a very similar issue to #7641 where Exceptions in Next.js are handled internally to create some kind of fallback behavior. In the case of DYNAMIC_SERVER_USAGE, it signals that the Server Component can't be pre-rendered at build time.

Actual Result

Once the build completes, see the Sentry Issue dashboard with "Dynamic server usage: Page couldn't be rendered statically because it used cookies"

[AbhiPrasad]

Hey @EnriqCG, thanks for writing in! It makes sense for us to not capture this error if you're intentionally trying to create dynamic components. PRs are welcome if you would like to help fix this! Otherwise we can also take a look in a bit.

[lforst]

Hm, I think this error has value and is actionable... I am not sure if we should ignore it.

[cysp]

The action I took after being surprised by these errors showing up in Sentry (at runtime in my case) was to explicitly mark the affected pages as requiring dynamic rendering (export const dynamic = 'force-dynamic'), which I guess is something but Next.js' documentation encourages an implementation where the dynamicity of a route is detected at rendering time, by observing use of a dynamic function (which results in this error)

https://nextjs.org/docs/app/building-your-application/rendering/server-components#switching-to-dynamic-rendering

As a developer, you do not need to choose between static and dynamic rendering as Next.js will automatically choose the best rendering strategy for each route based on the features and APIs used.

I'm curious about the value you see in highlighting these non-fatal errors, @lforst , I wouldn't say I'm an expert on this new app router world but it seems to be idiomatic to implicitly opt-in to dynamic rendering, as seen in the official documentation 🙂

[lforst]

@cysp I believe this is an error that is worth reporting. It is not idiomatic to have an app that throws this error at all. We should probably not report this error while building, but we should definitely report it when pages are regenerated (ISR) as it can lead to unexpected behavior.

For anybody stumbling onto this, the SDK will not crash anything or block any builds. It just picks up an error that is emitted during build or while regenerating pages.