Inconsistent Error Messaging / Handling in getStaticPaths

[ghost]

Verify canary release

• [X] I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 21.0.1: Tue Sep 14 20:56:24 PDT 2021; root:xnu-8019.30.61~4/RELEASE_ARM64_T6000
Binaries:
  Node: 16.14.2
  npm: 8.5.0
  Yarn: 1.22.19
  pnpm: N/A
Relevant packages:
  next: 12.3.2-canary.22
  eslint-config-next: 12.3.1
  react: 18.2.0
  react-dom: 18.2.0

What browser are you using? (if relevant)

Google Chrome (Version 105.0.5195.125 (Official Build) (arm64))

How are you deploying your application? (if relevant)

Locally via next dev

Describe the Bug

As a preface, this is absolutely human error, but still a possibility to improve error handling and developer experience as I (at least I hope 😅) am probably not the first or last to make this simple oversight.

Additionally, I apologize if this is a duplicate. I did attempt to find an existing report via Google and Github issue search; but at 1.2k open issues, I can't be 100% sure I didn't just miss it.

When creating dynamic routes in combination with getStaticPaths and getStaticProps, error handling does not cover / wrap when a non-string value is supplied as the parameter to a dynamic route.

I was able to Google my error message and figure out relatively quickly that the issue was I forgot to convert my page number from pagination data to a string as the argument for the paths property of the return; but this was not immediately clear.

EDIT: This appears to be as simple as just adding a type check and error to the escapePathDelivers() in router utils, but I am suspicious of it being that easy so a second opinion before I open a PR would be appreciated.

Expected Behavior

Incompatible return output from getStaticPaths would ideally be handled in the same way existing error handling is done for other problems. For example, if you omit a square bracket from the file, eg [[...page].jsx, or supply an array to a single-parameter route or a string to a catch-all route, then it gives a plain text error like "Segment names may not start or end with extra brackets ('[...page')." or "A required parameter (page) was not provided as an array" where it's immediately clear how to fix the problem.

Link to reproduction

https://github.com/jodylecompte/min-repro-nextjs-static-paths

To Reproduce

• Clone repo, install dependencies, and run dev server.
• Navigate to route /articles/3
• Error from screenshot above will be shown

[balazsorban44]

Thanks for raising this, I think the best place would be here:

https://github.com/vercel/next.js/blob/a78163dc613f168f991b29018adbc3472004d38b/packages/next/build/utils.ts#L972-L981

We could also change the error to TypeError, and maybe tweak the error message to "an array of string".

Feel free to open a PR for this, and I can follow up!

[frostzt]

@balazsorban44 I can pick this up! Lemme know if that's cool!

[ghost]

@frostzt I've actually already got the code written, I just ran out of time before having to clock in to open the PR. Sorry that I forgot to make note in the issue, busy morning!

[frostzt]

@jodylecompte no worries!

[reetbatra]

is this done? lemme know if i can pick this up

[moradebianchetti81]

hi, if this problem cannot be solved I would like to take it

[husseinraoouf]

@ijjk i know this issue isn't a high priority but it it would be nice to take a quick look at the linked PR to not keep those kind of easy bugs hanging

[Mitch5000]

Hey! I’d really like to work on this issue. I’ve spent a lot of time working with getStaticPaths and getStaticProps in dynamic routes, and I completely understand how easy it is to overlook a non-string parameter—especially with pagination logic.

Improving developer experience through clearer error messaging is something I’m passionate about, and this feels like a great opportunity to contribute a small but meaningful enhancement. I’ve reviewed the code in escapePathDelimiters and agree it may be as simple as adding a type check and throwing a more descriptive error. I'd be happy to explore this further and open a PR, pending any guidance from the team. Let me know if this is something you'd be open to!

[Prasad-JB]

Hi! I’d like to work on improving the error messaging for getStaticPaths when a non-string parameter is passed to dynamic routes. I can add a type check to escapePathDelimiters() and ensure the output aligns with the existing error style for similar routing issues. Could you please assign this to me? Thanks!

[tysoncung]

I'm interested in working on this issue. Could you provide more context about what you're looking for? Any additional details about requirements or constraints would be helpful.

[SamarthPD-21]

Hi, I was going through this issue and noticed there’s no open PR for it. I’d like to implement the type check in escapePathDelimiters() to improve the error handling for non-string segments. Would that be okay?

[reckziegelwilliam]

@balazsorban44 Hi, I’d like to fix this one. I’ve read through the description, repro, and contributing guide, and I have a clear idea of how to approach it. If no one else is actively working on it, I can put together a PR with tests/docs updates. – Liam