-
Notifications
You must be signed in to change notification settings - Fork 489
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
Pass request context to the logger #1236
Labels
Comments
Go's |
mmhand123
added a commit
to mmhand123/tusd
that referenced
this issue
Jan 14, 2025
This allows the logger passed to the tusd handler to access the request specific context and pull out things like sentry information or trace information. Implements tus#1236
Acconut
pushed a commit
that referenced
this issue
Jan 14, 2025
* chore: Pass request context to logger when logging This allows the logger passed to the tusd handler to access the request specific context and pull out things like sentry information or trace information. Implements #1236 * chore: bump exp and update log to use Context
Implemented in #1237, thank you! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
We're trying to integrate handling errors as they come up with sentry and am trying to capture exceptions any time errors come up in TUS. What I've landed on so far, which might not be the best way, is to implement a custom handler for the logger I pass to TUS so that whenever an error log comes in, it captures an exception to Sentry. This works but is missing some request specific context that gets setup when doing routing.
It would be great if logging had access to the request context here.
Describe the solution you'd like
Ideally the logger would have access to the request context via
c.log.ErrorCtx
(orInfoCtx
etc). This way my custom handler can pull out the sentry information from the request context.Describe alternatives you've considered
Right now it's just capturing generic exceptions, which somewhat works, but is missing important information. Not sure of other ways to achieve what we want but open to any suggestions!
Can you provide help with implementing this feature?
Yes, I can provide a PR if it seems to be a good solution!
The text was updated successfully, but these errors were encountered: