ISR with revalidate & searchParams in App Router: DYNAMIC_SERVER_USAGE error & caching concerns

[petrch87]

Summary

I am encountering a DYNAMIC_SERVER_USAGE error in my Next.js 15 App Router application when trying to implement Incremental Static Regeneration (ISR) for pages that access searchParams. My setup involves a catch-all route ([[...slug]]/page.tsx) with export const revalidate = 120; and an empty generateStaticParams function, as I intend for pages to be generated on-demand and then cached. While this works for pages without searchParams, accessing searchParams in my Server Component (PageComponent) causes pages with query parameters to result in an error in production (even though it works in development). My goal is to have pages, including those differentiated by searchParams, cached and revalidated like standard ISR pages. The application fetches content from a CMS based on both the slug and query parameters, and I expect high traffic. I have read other issues and found out that this might not be possible. Considering this scenario, is Next.js a suitable choice for a high-traffic site like this? I would assume that being able to cache pages with searchParams, even with some setup, should be a basic feature.

Additional information

My application is a proof-of-concept for a large news company (expecting ~50 million views/month) and we are considering migrating from a PHP/Varnish stack, where caching URLs with query parameters is standard. The CMS I'm working with serves content where both the URL path (slug) and searchParams can define the page content. Not all of my pages will use searchParams, but I don't know ahead of time which ones will. I am seeking clarification on whether Next.js's ISR can support caching distinct versions of a page based on searchParams (e.g., /article/slug and /article/slug?variant=b being cached separately and revalidated) or if I need to consider alternative approaches for this high-traffic scenario. The DYNAMIC_SERVER_USAGE error appears when Next.js attempts to handle a route with searchParams under my ISR configuration.

Core Application Logic:

The basic workflow is that for any incoming URL (captured by my catch-all route app/[[...slug]]/page.tsx), my PageComponent takes the path segments (slug) and any searchParams. It then constructs a specific URL to query our headless CMS. This CMS returns a JSON payload that essentially defines the entire page structure, including what components to render and with what data. My React components then parse this JSON and dynamically render the page accordingly. This means the exact content and layout of a page can be heavily influenced by both the path and the query parameters, as they both feed into the CMS query.

Relevant Code Snippets:

1. Catch-all Route (app/[[...slug]]/page.tsx):
This is how I've set up ISR with revalidate and an empty generateStaticParams for on-demand page generation and caching.

// app/[[...slug]]/page.tsx
import PageComponent from '@/components/PageComponent'; // Actual path might vary

type PageProps = {
    params: { slug: string[] };
    searchParams: { [key: string]: string | string[] | undefined };
};

export default async function Page(props: PageProps) {
    return <PageComponent pageProps={props} />;
}

export const revalidate = 120; // Revalidate every 120 seconds

export async function generateStaticParams() {
    // Intend for pages to be generated on-demand and then cached
    return [];
}

2. Server Component accessing searchParams (PageComponent.tsx):
This component receives searchParams and uses them to construct the URL for fetching data from my CMS. Accessing searchParams here seems to be what triggers the DYNAMIC_SERVER_USAGE issue in production builds when revalidate is used.

// components/PageComponent.tsx (Simplified)
'use server';

// Simplified type for example clarity
// type UrlResponse = { data: { content: string; title: string } }; 

type PageComponentProps = {
    pageProps: {
        params: { slug: string[] };
        searchParams: { [key: string]: string | string[] | undefined };
    };
};

export default async function PageComponent({ pageProps }: PageComponentProps) {
    const { slug } = pageProps.params;
    const searchParams = pageProps.searchParams; // Accessing searchParams

    const urlString = slug?.join('/') || 'home'; // Default to 'home' if no slug
    let cmsApiUrl = `${process.env.NEXT_PUBLIC_CMS_API_URL}/${urlString}`;

    const queryParts: string[] = [];
    if (searchParams) {
        for (const [key, value] of Object.entries(searchParams)) {
            if (value === undefined) continue;
            if (Array.isArray(value)) {
                value.forEach(v => queryParts.push(`${encodeURIComponent(key)}=${encodeURIComponent(v)}`));
            } else {
                queryParts.push(`${encodeURIComponent(key)}=${encodeURIComponent(value)}`);
            }
        }
    }
    
    if (queryParts.length > 0) {
        cmsApiUrl += `?${queryParts.join('&')}`;
    }

    // console.log('Fetching from CMS URL:', cmsApiUrl);
    const response = await fetch(cmsApiUrl, { next: { revalidate: 120 } }); // Data fetch revalidation

    if (!response.ok) {
        // Handle error appropriately
        throw new Error(`HTTP error! status: ${response.status} for URL: ${cmsApiUrl}`);
    }

    const data = await response.json(); // Assuming JSON response

    // Simplified rendering for example - in reality, this maps to complex React components based on CMS JSON
    return (
        <div>
            {/* <h1>{data.data.title}</h1>
            <div>{data.data.content}</div> */}
            <p>Page for: {urlString}{queryParts.length > 0 ? `?${queryParts.join('&')}` : ''}</p>
            <p>CMS data would be mapped to components here.</p> 
        </div>
    );
}

Any help would be much appreciated

Example

No response