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

Log route for exceptions #1736

Open
1 task
septatrix opened this issue Sep 18, 2023 · 5 comments
Open
1 task

Log route for exceptions #1736

septatrix opened this issue Sep 18, 2023 · 5 comments
Labels
dx enhancement New feature or request

Comments

@septatrix
Copy link
Contributor

Describe the feature

I am currently using Nuxt to write an application. As it is almost impossible to check for every eventuality during development there are sometimes exception logged on production. However, as everything is bundled, the stack traces are not really useful and do not give any hint as to which route was causing the problem.

In those cases it would greatly simplify troubleshooting if some information about the request is also logged for exceptions.

In some cases it is possible to find the handler file ( ./.output/server/chunks/foobar.get.mjs) listed as part of the stack trace though that is not always the case. For example I have to error messages [nuxt] [request error] [unhandled] [500] The first argument must be of type string or an instance of Buffer, ArrayBuffer, or Array or an Array-like Object. Received an instance of URLSearchParams and [nuxt] [request error] [unhandled] [500] Cannot set headers after they are sent to the client where I do not know from which handler they originate. Therefore I am also not sure if this might be my fault or something within Nuxt which is failing - and I have no good way to create a reproducible example to figure that out and maybe raise a proper issue here.

Additional information

  • Would you be willing to help implement this feature?
@pi0 pi0 added enhancement New feature or request dx and removed pending triage labels Sep 18, 2023
@pi0
Copy link
Member

pi0 commented Sep 18, 2023

Nice idea! We can achieve this using new Native Async Context and Error Capturing Hooks.

@septatrix
Copy link
Contributor Author

Looking at the linked error hook announcement it seems like async context might not even be required. I will try to get it running with defineNitroPlugin() in Nuxt once I have a bit of time to play around the coming days

@pi0
Copy link
Member

pi0 commented Sep 18, 2023

Thanks but we definitely need ALS to track requests. Nitro plugins, unlike nuxt do not preserve context during per-request call (but run once during startup).

You might try something with error hook btw and log it in a nitro plugin with more error context, that's possible.

@septatrix
Copy link
Contributor Author

Yeah I was referring to the latter. Basically what's already written in the error hook code snippet from the release announcement (except replacing hookOnce with hook):

export default defineNitroPlugin((nitro) => {
  nitro.hooks.hook('error', async (error, { event }) => {
    console.error(`${event.path} Application error:`, error)
  })
})

@pi0
Copy link
Member

pi0 commented Sep 18, 2023

Feel free to open a PR to unjs/website it must have been a typo with hookOnce!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dx enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants