app router does not resolve routes according to `generateStaticParams` constraints

[y-nk]

app router does not resolve routes according to `generateStaticParams` constraints

[y-nk]

yes it is. but i doubt fixing the dev server will be easier. this is a 3 lines patch which can be applied with patch-package and gives the hand to userland through the middleware. so i think it's pretty ok until the maintainers finally decide to have a look at this. (cc @leerob i had mentioned this to you on X)

[abhi12299]

yeah - its' not a trivial fix. let's see what happens with this

[y-nk]

somehow related: #53887

[y-nk]

looking further, the regexes generated for the routes seem to ignore totally the generateStaticParams

[y-nk]

after a good round of console.log (and from my candid PoV of next), it seems like the AppPageRouteMatcher does not contain data from getStaticParams, therefore it's impossible to get an accurate route matching.

Route definition is passed here, but lacks of any kind of ref to getStaticParams :/

next.js/packages/next/src/server/route-matcher-providers/app-page-route-matcher-provider.ts

Lines 43 to 45 in a5f30e6

	const filename = this.normalizers.filename.normalize(manifest[page])
	const bundlePath = this.normalizers.bundlePath.normalize(page)

[y-nk]

of course i want to state clear that i know this:

but still routes imho should abide to the result of this function and pass to other matchers before making a decision. here is seems the logic is → match the path blindly regardless of the values in params, then render the route no matter what.

it's utterly deceptive because it's like not using a data validation library (the valid values returned from generateStaticParams) and then pass unvalidated/wrong values to a component.

[abhi12299]

good find, @y-nk.. I'm looking into this and found out that this only happens in dev mode. Production build works as expected. The issue you linked has a PR by one of the maintainers: #54364 - I this issue is stemming from the code changes here. Will investigate further.

Update: this has nothing to do with this PR. The behaviour of the generateStaticParams function in dev mode as you highlighted above is the reason for this issue. The route regex being made does not take into consideration the static params for a given page. It just creates those regexes based on the folder structure. I'm not sure if the maintainers would want to change this behaviour :/

[y-nk]

@abhi12299 i have found an (slightly ugly) way to make it work, which i think could be used as a "ultimate manual mode" feature.

currently my idea is to add some code for manual/force route matching based on headers here:

next.js/packages/next/src/server/lib/router-utils/resolve-routes.ts

Lines 264 to 272 in a5f30e6

	for (const route of dynamicRoutes) {
	// when resolving fallback: false the
	// render worker may return a no-fallback response
	// which signals we need to continue resolving.
	// TODO: optimize this to collect static paths
	// to use at the routing layer
	if (invokedOutputs?.has(route.page)) {
	continue
	}

such as:

            for (const route of dynamicRoutes) {
              if (req.headers['x-resolved-route']) {
                // skip the desired route was provided in headers
                if (route.page !== req.headers['x-resolved-route']) {
                  continue;
                }
              }

then we can add this internal header in the middleware like this:

[abhi12299]

This is equivalent to hard coding the route match rules in the codebase.