Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show prerender error details #2992

Open
Joery-M opened this issue Jan 13, 2025 · 1 comment
Open

Show prerender error details #2992

Joery-M opened this issue Jan 13, 2025 · 1 comment

Comments

@Joery-M
Copy link

Joery-M commented Jan 13, 2025

Environment

Nitro: 2.10.4
Node: 18.20.3 (stackblitz) and 20.16.0 (local test)

Reproduction

https://stackblitz.com/edit/github-3wg9izmg?file=nitro.config.ts&view=editor

Describe the bug

When returning an error like this:

export default eventHandler((event) => {
  return Error("Returning error");
});

The error reason is not shown in the console when prerendering:

Errors prerendering:
  ├─ /returnError (2ms)
  │ └── [500]

This case is the same if an error is thrown, but then at least a stack trace will appear:

export default eventHandler((event) => {
  throw Error("Throwing error");
});
ℹ Prerendering 3 routes
[nitro] [request error] [unhandled] Throwing error
  at Object.eval (./.nitro/prerender/chunks/routes/throwError.mjs:19:9)  
  at eval (./node_modules/h3/dist/index.mjs:2016:43)  
  at async Object.eval (./node_modules/h3/dist/index.mjs:2088:19)  
  at async toNodeHandle (./node_modules/h3/dist/index.mjs:2380:7)  
  at async ufetch (./node_modules/unenv/runtime/fetch/index.mjs:28:17)  
  at async generateRoute (./node_modules/nitropack/dist/core/index.mjs:1984:17)
  ├─ /throwError (4ms)
  │ └── [500]

Additional context

This issue stems from this Nuxt issue, which stems from trying to debug this Pinia issue

In the Nuxt issue, I suggested a solution in the now removed normalizeError function, but that solution doesn't apply here since the function was removed.

The only way I have found that an error will show nicely, is when setting the response status to 500, and providing text.
Personally I would also like to see some sort of stack trace for further debugging, but I will leave that up to be debated about.

As mentioned by Daniel Roe, using createError is indeed the preferred way of returning an error. But that still does not properly show the error if you don't explicitly set statusMessage

Logs

No response

@pi0
Copy link
Member

pi0 commented Jan 13, 2025

You should ideally throw errors not return them. (it can cause other unwanted effects)

But I think we might also try to detect this edge case for pretender DX.

@pi0 pi0 changed the title Returning an Error will not show in console during prerendering Show prerender error details Jan 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants