Search params are undefined when draft mode is enabled

[MangoMarcus]

Link to the code that reproduces this issue

https://github.com/MangoMarcus/nextjs-draft-mode-empty-search-params

To Reproduce

1. Clone the repository and spin up locally with npm i and npm run dev
2. Use the two buttons at the top to toggle draft mode on and off
3. The 'token' parameter shows 'undefined' when draft mode is off, and 'foo' when it's on
4. Deploy to Vercel, or use mine: https://nextjs-draft-mode-empty-search-params.vercel.app/?token=foo
5. Use the buttons again - the 'token' parameter shows 'undefined' when draft mode is off, but also 'undefined' when it's on

Current vs. Expected behavior

Locally the token correctly displays as 'foo' with draft mode enabled, but on Vercel it's 'undefined'. Vercel should also show 'foo'.

Interestingly there's also a discrepancy between urlPathname and isRevalidate between local and vercel shown in the screenshots below

Local - dev mode (npm run dev)

Draft mode disabled

Draft mode enabled

Local - production build (npm run build && npm start)

Draft mode disabled

Draft mode enabled

Vercel

Draft mode disabled

Draft mode enabled

Provide environment information

Operating System:
  Platform: macOS
  Chip: Apple M1 Pro
  Version: macOS 14.4
Binaries:
  Node: 20.2.0
  npm: 9.6.6
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.4
  eslint-config-next: N/A
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.5.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Output (export/standalone), Runtime

Which stage(s) are affected? (Select all that apply)

Vercel (Deployed)

Additional context

The problem might stem from the search parameter being accessed dynamically, depending on if draft mode is enabled.

If draft mode is enabled then the page is rendered dynamically and dynamic features like search parameters and cookies should be available. If it's disabled, then it's rendered statically and all search parameters should returned undefined.

My example shows that draft mode is correctly enabled - and therefore the page is being rendered dynamically at request time - but the dynamic features are not available.

Edit: Added local production build examples

[MangoMarcus]

As an aside, how actively are these issues monitored? I've submitted 2 bugs months ago which have yet to be acknowledged by a maintainer

[MangoMarcus]

Edited to add an example of a production build run locally which also works as expected, which confirms a discrepancy between a production app built and run locally vs on Vercel

[samcx]

As an aside, how actively are these issues monitored? I've submitted 2 bugs months ago which have yet to be acknowledged by a maintainer

@MangoMarcus Actively as possible! We are currently taking a look at this.

[MangoMarcus]

As an aside, how actively are these issues monitored? I've submitted 2 bugs months ago which have yet to be acknowledged by a maintainer

@MangoMarcus Actively as possible! We are currently taking a look at this.

Thanks @samcx 🙏

[samcx]

@MangoMarcus It turns out your page was not bailing out of ISR (static) because searchParams was accessed conditionally (searchParams.token). This is because we don't know if searchParams is going to be accessed until runtime.

I tried just adding:

<pre>{JSON.stringify(searchParams)}</pre>

Afterwards, token is no longer undefined.

• https://github.com/MangoMarcus/nextjs-draft-mode-empty-search-params/blob/4e07c5d9a2b885e48b2f1260a4062dff074244f4/src/app/page.tsx#L18

I am curious though as to why you want to access your searchParams and make your page dynamic? I believe this defeats the purpose of Draft Mode, which is a way to preview your static page dynamically.

[MangoMarcus]

Thanks @samcx , sorry for the delayed response.

---

I am curious though as to why you want to access your searchParams and make your page dynamic? I believe this defeats the purpose of Draft Mode, which is a way to preview your static page dynamically.

I don't, I only want the search params in draft mode

When draft mode is disabled, I want to render the page statically using data fetched from my headless CMS, which is identified using the current URL path

When draft mode is enabled, I want to render the page dynamically using data fetched from my headless CMS, which is identified using the current URL path AND a token from the search params (which matches a draft version of the page in my CMS)

---

It turns out your page was not bailing out of ISR (static) because searchParams was accessed conditionally (searchParams.token).

That's correct, the search params are conditionally accessed only if draft mode is enabled (which obviously bypasses static rendering with a cookie).

This behaviour is supported by nextjs, but not when hosted on Vercel. This is confirmed by running the app locally with npm run build and npm run start, or when running it on another platform such as Netflify: https://soft-gumdrop-5ab214.netlify.app/?token=foo

Surely this qualifies as a bug? You'd at least expect the behaviour to be the same. I've confirmed that it's the same in the latest Next v15

✅ localhost: http://localhost:3000/?token=foo

✅ Netflify: https://soft-gumdrop-5ab214.netlify.app/?token=foo

❌ Vercel: https://nextjs-draft-mode-empty-search-params.vercel.app/?token=foo

[MangoMarcus]

Just to clarify

I tried just adding:

{JSON.stringify(searchParams)}

Afterwards, token is no longer undefined.

This would opt the page in to always be dynamically rendered, correct? I still want it to render statically, unless draft mode is enabled

[jalada]

I'm also encountering this issue. I want to access searchParams in draft mode only, to extract a version parameter to use when hitting my headless CMS. Locally this works, but in Vercel, I can see that the page is being dynamically rendered in draft mode (good!) but the code isn't getting the search params (?!).

[MangoMarcus]

@jalada nice to have company! Vercel support have basically washed their hands of this as the expected behaviour, even though it works fine locally using a production build, and on Netlify, but not Vercel. Maybe the fix is to move to Netlify 🤔

After thorough testing, the team confirmed that the behavior you’re seeing is expected. Search parameters are filtered out during ISR (including when draft mode is enabled) to ensure consistency between draft and production rendering. This is the intended behavior across both the Pages Router and the App Router.

They did however suggest a workaround using headers instead of search params, I haven't tested that but it wouldn't work in my case anyway because I don't have control over the headers coming from my CMS backend.

That said, there is another approach that should work well for your use case. Instead of passing the token through search parameters, you can send it via headers and then conditionally read headers() when draft mode is active. This way, you’ll be able to keep static rendering as the default while still enabling dynamic rendering in draft mode.

I'm not sure why headers should work but search params shouldn't during dynamic rendering anyway to be honest. As you say, the page is being rendered dynamically as expected - it's just not providing the search params from the request.

[jalada]

Thanks @MangoMarcus. I agree that if this is by design, it seems a strange decision.

I did wonder if headers would be subject to the same 'design choice'. I'm wondering now if I could set a header in middleware based on the searchParam I'm using, and then read that.

I'll have a crack and report back.

[jalada]

It's crazy, but it works. I added this middleware:

const handleVersionParam = (
  request: NextRequest,
  response: NextResponse
): void => {
  const url = request.nextUrl;
  const version = url.searchParams.get(VERSION_PARAM);

  if (!version) {
    return;
  }

  // TODO: Might also be worth checking for the draft mode cookie, but since
  // it's pretty undocumented, could be a brittle test, and probably doesn't
  // matter.

  response.headers.set('x-content-version', version);
};

And then conditionally fetch headers in the page to extract the version:

function Page() {
  // <...>

  const { isEnabled: isDraftMode } = await draftMode();
  // it's important to only attempt to access headers if draft mode is
  // enabled. If you access it unconditionally, the whole page will be opted
  // in to dynamic rendering.
  const version = isDraftMode
    ? (await headers()).get('x-content-version')
    : undefined;

  // <...>
}

It feels like this only further confirms that this is a bug tbh. All I had to do was swap await searchParams for await headers() and swap to a get accessor. Functionally, everything is otherwise identical to the old approach, just reading headers instead of search params.