The APIs listed with “PARAM” don’t work and we are trying to determine what changed. The first site shows deployment with Next.js Runtime v4.7.0 while the second/newer one shows v4.27.1. The branch of the new site works locally as well.
We also noticed in the log drains that requests to our function endpoints are listed as “(SSR)” in the original site but “(API)” in the new site. We don’t currently use a netlify.toml file.
Any pointers on where to look to understand this change would be appreciated.
Hey @metriedevs, it sounds like you might be running into an issue which our engineering team is already investigating. That said, I’m wondering if you can try updating the Next.js Runtime to version 4.27.2 to see if that changes the behavior? You can do this manually by adding the following in the package.json file:
We used to reference req.query.productGroup as the path parameter. However, we only ever get back the literal value [productGroup] in the function. As an example, the request to: /api/search/test?page=1 provides the following to NextApiRequest.query:
{ "page": "1", "productGroup": "[productGroup]" }
I’m also seeing this header in NextApiRequest.rawHeaders:
"x-matched-path" = "/api/search/[productGroup]"
We just aren’t sure what changed or what we need to do to correct this.
If that does not resolve this, please let us know. Also, if this doesn’t resolve this, would you please share the output of the build logs (or a link to them as our support team can see even private build logs)?
This seems to be happening with the recent change to split out API routes into their own individual functions. I can’t confirm if you’re affected by the same issue or not as I can’t any see error message inside your function logs, but to confirm (and sorry to suggest this after so much back-and-forth about versions), are you able to see this error when you downgrade to a version that didn’t use this API splitting? The last version that didn’t have this feature was v4.26.0. If by downgrading to that there are no errors, this update seems to have caused issues for you too.
@hrishikesh Thank you very much for replying, however, due to a deadline we ended up switching from path parameters to query string parameters. Unfortunately we don’t have the time to see this issue get resolved. Thanks again.
Hello @metriedevs - I can completely understand competing priorities. Thank you for your update here and if you so choose to revisit this topic at a later date, we will be here!