AI & Agent Dev Bug Sandbox Back to Radar

Incorrect Error Message When Awaiting Params Under 'Use Cache'

Next.js reports an error that mentions 'searchParams' when the actual inaccessible dynamic data is 'params' inside a 'use cache' context. This misleads developers by pointing to the wrong property, causing confusion and wasted debugging time.

mediumConfidence 85%Next.js Affected V16.3.4 Affected V16.4.0-Canary.13

Origin Analysis

The error generation for prohibited dynamic request data inside 'use cache' uses a hardcoded property name 'searchParams' instead of dynamically reflecting whether 'params' or 'searchParams' was accessed. The two proxy handlers likely share a common error string that does not accept the property name as a parameter.

1. Create a Next.js app with App Router and enable 'use cache'. 2. Create a dynamic route app/[slug]/page.tsx with an async function that does `const { slug } = await params` inside a cached function. 3. Run `next dev` and navigate to /[slug]. 4. Observe the error message incorrectly references `searchParams` even though `params` was used.

Fixing Code Block

// Step 1: Create new shared error generator
export function createUseCacheError(property: 'params' | 'searchParams', route: string): string {
  return `Route "${route}": \`${property}\` can't be read inside \`"use cache"\`. Await it outside the cached function and pass what you need as an argument. Learn more: https://nextjs.org/docs/messages/next-request-in-use-cache`;
}

// Step 2: In params proxy, replace error throw with:
// throw new Error(createUseCacheError('params', route));

// Step 3: In searchParams proxy, replace error throw with:
// throw new Error(createUseCacheError('searchParams', route));

Introduce a shared error generator function that accepts the actual property name ('params' or 'searchParams') and the route string. Then update both proxy handlers to pass the correct identifier, eliminating the hardcoded 'searchParams' message for params access.

Edge Case Audit

This fix changes only the error message text; no runtime behavior changes. However, any tooling, tests, or log filters that rely on the exact old error string may break. Rollback is safe by reverting the affected files. If future Next.js updates modify the same files, the patch may require rebasing.