Inconsistent behavior of generateStaticParams

[mastoj]

I had this bug registered that I think was closed too early: #84801

For any good framework or library consistency in behavior is crucial long term. If I as a user needs to think about some features having different effects in different circumstances it will be hard to know when to do what over time.

In the specific bug and in the reproduction I have created I noticed a difference in behavior when I used generateStaticParams.

First let's explain how I, and probably a lot of other developers see generateStaticParams. The function is there to generate an array of values representing the params for the pages you want to prerender. In other words, all the values not present in the array will not be prerendered. This is perfectly fine, but what I find strange is take a path like product/[id] and try to go to product/2 it behaves differently if you have generateStaticParams = () => [{}] and generateStaticParams = () => [{id:"1"}].

Note that in both cases I do NOT include the id "2". So in other words I tell nextjs that product/2 should not be prerendered in both scenarios and therefor in both scenarios I expect the page product/2 to be treated the same if I have generateStaticParams = () => [{}] and generateStaticParams = () => [{id:"1"}], which is not the case.

To see the difference in action you can visit these two pages:

https://next16-demo-git-static-params-bug-mastojs-projects.vercel.app/wat/anyslug
https://next16-demo-git-static-params-bug-mastojs-projects.vercel.app/anyslug

Both are identical except for the generateStaticParams. Code for the repro is here: https://github.com/mastoj/next16-demo/tree/static-params-bug

[DanielSalazarLoaiza]

This difference occurs because generateStaticParams directly influences how Next.js builds the route segment’s static vs. dynamic behavior.

When you return [{ id: "1" }], Next.js treats the[id]segment as partially static, generating a static route for id=1 and expecting a 404 for others.
When you return [{}], the empty param causes the segment to be treated as fully dynamic, enabling runtime fallback behavior.

In other words, generateStaticParams not only defines which pages are prerendered but also implicitly affects the runtime resolution mode of that route (static, dynamic, or fallback). This is why product/2 behaves differently between the two cases — one configuration tells Next.js to build statically with no fallback, the other triggers dynamic rendering.

It would definitely help if the docs clarified that an empty object changes the route generation mode, not just the pre-rendered params.

[mastoj]

First, I had a typo above, should have been [] not [{}].

I am perfectly fine that it influences static vs dynamic, but it needs to be consistent which is not. Returning null or undefined can have that impact because it is more explicit, but if I return [{id: 1}] and that impacts /12345 differently compared to [] I find it strange in my opinion and feels to magical. In both scenarios 12345 has been left out in the array, so in both scenarios it should be treated the same. An empty array is not the same as null or undefined.

[DanielSalazarLoaiza]

You're absolutely right — returning [] should ideally behave consistently and not introduce implicit dynamic fallback behavior.

The issue here is that generateStaticParams currently acts as both:

1. A build-time hint (what to pre-render).

2. A runtime mode signal (whether the route is treated as static or dynamic).

When you return [], the compiler interprets that as “this segment is static but with no generated paths,” and therefore it omits dynamic fallback handling entirely.
When generateStaticParams is omitted (or undefined), the segment is considered dynamic and uses runtime resolution.

So technically, [] ≠ undefined — but the distinction isn’t well documented and feels unintuitive, since both scenarios mean “no paths to pre-render.”

I completely agree that this behavior could be normalized or at least clearly documented. Right now, the implicit dual role of generateStaticParams makes it easy to misunderstand its side effects on route behavior.

[mastoj]

I think you are missing slightly what I am saying, or I am misunderstanding what you are writing :).

I understand that it is both a build-time hint and runtime signal. When I have [] or [{id: "1"}] it should mean that this is static, right? The difference here is that the second also states that {id: "1"} should be pre-rendered, correct? This means, in my head that all other routes are not pre-rendered but they should be treated the same way. So when I visit a route corresponding to {id: "123123"} it should behave the same in both scenarios.... and that is where the inconsistency is. [] and [{id: "2"}] results in different behavior for urls that are not prerendered. You see the difference in behavior clearly here:

https://next16-demo-git-static-params-bug-mastojs-projects.vercel.app/wat/anyslug
https://next16-demo-git-static-params-bug-mastojs-projects.vercel.app/anyslug

The only difference between those two routes is [] vs [{id: "1"}], so as I see it they should behave the same.

Here are the code for the pages:
https://github.com/mastoj/next16-demo/blob/static-params-bug/app/%5Bid%5D/page.tsx
https://github.com/mastoj/next16-demo/blob/static-params-bug/app/wat/%5Bid%5D/page.tsx