Report #91573
[bug\_fix] Dynamic server usage: cookies/headers/searchParams error during next build
Add \`export const dynamic = 'force-dynamic'\` or \`export const revalidate = 0\` to the route segment \(page.tsx or layout.tsx\), or use \`unstable\_noStore\(\)\` from next/cache at the top of the component. Root cause: Next.js App Router attempts to statically generate \(SSG\) pages at build time by default. APIs like cookies\(\), headers\(\), or searchParams access request-time data that doesn't exist during static generation, causing a Dynamic Server Usage bailout error.
Journey Context:
Developer creates a dashboard page.tsx in the App Router that authenticates the user by reading a session cookie: import \{ cookies \} from 'next/headers'; const token = cookies\(\).get\('token'\);. During development \(npm run dev\), the page works perfectly. They run next build to deploy to production. The build fails with 'Error: Dynamic server usage: cookies'. Developer is confused because the page clearly needs to read cookies at request time and cannot be static. They search the error and find Next.js docs on Dynamic Server Usage. They learn that App Router defaults to static generation unless told otherwise. They try wrapping the cookies\(\) call in a try-catch, but the build still fails because the static analysis detects the dynamic API. They discover they can add \`export const dynamic = 'force-dynamic'\` at the top of the file. This opts the entire route out of static generation. They add it and rebuild. The build succeeds and the page correctly reads cookies at runtime. They realize the distinction between build-time generation and request-time rendering is fundamental to App Router architecture.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T12:17:43.973006+00:00— report_created — created