Temporarily removing the dev warnings. I've moved these to be errors in the build side. In a follow up PR I will use prerendering during dev to trigger these errors and report them as dev errors as well. This also updates how we track sync dynamic errors. The main goal is to have a stack trace of the sync function and separately report all the component stacks that might contain this function call. It's not fool-proof b/c the sync api may be called in a way that is not observed by SSR. The whole debugging story here will improve dramatically with owner stacks but that is currently experimental only in React. The plan for future updates is to add a prospective render for SSR so we can flush out module scope issues like calling Math.random while lazy initializing a module. This is asserted for RSC in this change (see new tests) but won't wouldn't pass for SSR b/c we only do single pass prerendering at the moment. After that I will add in the prerender-while-render in dev and utilize the prerender errors to power dev as well.
3.8 KiB
title
| title |
|---|
| Cannot access Request information synchronously with `cookies()`, `headers()`, or `draftMode()` |
Why This Error Occurred
In Next.js 15 global functions that provide access to Request Header information such as cookies(), headers(), and draftMode() are each now async and return a Promise rather than the associated object directly.
To support migrating to the async APIs Next.js 15 still supports accessing properties of the underlying object directly on the returned Promise. However when dynamicIO is enabled it is an error to do so.
Possible Ways to Fix It
If you haven't already followed the Next.js 15 upgrade guide which includes running a codemod to auto-convert to the necessary async form of these APIs start there.
If you have already run the codemod on your project look for instances of the string @next-codemod-error to see where the codemod was unable to convert to the async form. You will have to refactor your code manually here to make it compatible with the new result type.
Before:
// This function is sync and the codemod won't make it async
// because it doesn't know about every callsite that uses it.
export function getToken() {
// @next-codemod-error ...
return cookies().get('token')
}
import { getToken } from '.../token-utils'
export default function Page() {
const token = getToken();
validateToken(token)
return ...
}
After:
export async function Page() {
return (await cookies()).get(token)
}
import { getToken } from '.../token-utils'
export default async function Page() {
const token = await getToken();
validateToken(token)
return ...
}
If you do not find instances of this string then it is possible the synchronous use of Request Header data is inside a 3rd party library. You should identify which library is using this function and see if it has published a Next 15 compatible version that adheres to the new Promise return type.
as a last resort you can add await connection() before calling the 3rd party function which uses this API. This will inform Next.js that everything after this await should be excluded from prerendering. This will continue to work until we remove support for synchronously access Request data which is expected to happen in the next major version.
Before:
import { getDataFrom3rdParty } from '3rdparty'
export default function Page() {
// Imagine this function access Request data synchronously
// on the inside even if it has an async external interface
const token = await getDataFrom3rdParty();
return ...
}
After:
import { connection } from 'next/server'
export default async function Page() {
await connection()
// Everything from here down will be excluded from prerendering
const token = await getDataFrom3rdParty();
validateToken(token)
return ...
}
Note that with await connection() and dynamicIO it is still required that there is a Suspense boundary somewhere above the component that uses await connection(). If you do not have any Suspense boundary parent you will need to add one where is appropriate to describe a fallback UI.