Closed emosbaugh closed 11 months ago
Hi @emosbaugh
Apologies for the delayed response, and thank you for your patience.
Can I ask what errors
package is being referred to when you call errors.New()
? From some investigation, it looks like the standard library's errors
package does not include stack traces, but the github.com/pkg/errors
package would instead capture a stack trace: https://stackoverflow.com/questions/61933650/whats-the-difference-between-errors-wrapf-errors-errorf-and-fmt-errorf#:~:text=*The%20github.com,popular%20for%20that.
We suspect the reason unknown method:0
is shown here is because the innermost exception has unknown method
being reported, and so this is what is displayed in the UI. Can you confirm which errors
package you are using? And if you are using the standard library's errors
package, are you able to test whether implementing github.com/pkg/errors
instead makes any difference?
If you continue to have issues with this and want to share more information that you'd prefer not to be public, please feel free to open a ticket with us directly by contacting support@bugsnag.com.
Hi @mclack
Yes we are using the go standard library "fmt"
package and creating an error with the %w
wrap verb. This creates a *fmt.wrapError
which conforms to the bugsnag-go/errors.errorWithCause
interface.
The issue is that unlike the github.com/pkg/errors package, the cause does not have a stack.
You can see my code snippet for reproduction.
To work around the issue I can port all my code to use errors.Wrap(err, "...")
rather than fmt.Errorf("...: %w", err)
but I'd rather not.
I will open an additional ticket with support@bugsnag.com referring to this issue.
Thank you, Ethan
Hi @emosbaugh We are currently investigating this issue and will reach out once we have more information to share.
Thanks!
Sent via Superhuman @.***>
On Tue, Nov 07, 2023 at 3:36 AM, Christian Rafferty < @.***> wrote:
Hi @emosbaugh https://github.com/emosbaugh We are currently investigating this issue and will reach out once we have more information to share.
— Reply to this email directly, view it on GitHub https://github.com/bugsnag/bugsnag-go/issues/201#issuecomment-1798332563, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC2U57XFNSLXRKKITJHZ2TYDIMLPAVCNFSM6AAAAAA6D3R6D6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJYGMZTENJWGM . You are receiving this because you were mentioned.Message ID: @.***>
Hi @emosbaugh
Unfortunately we are limited in what we can do with errors reported from the standard library as these errors do not have a stack trace. We would recommend switching to using the github.com/pkg/errors
library instead to gain full insight into these errors.
I'm going to close this ticket out now, but feel free to reopen if you have any further questions.
Hello.
Opening this one back up. I'm hesitant to use the https://github.com/pkg/errors errors library as it has been archived by the owner on Nov 30, 2021. It is now read-only.
Best, Ethan
Hi @emosbaugh
Thanks for highlighting that. I've found a new Go package, which seems to be the successor to https://github.com/pkg/errors, and is actively maintained: https://gitlab.com/tozd/go/errors
You can find the documentation here: https://pkg.go.dev/gitlab.com/tozd/go/errors#section-documentation
Before deciding on how you'd want to approach capturing stack traces, it may be worth reading this DoltHub blog on capturing stack traces in Go first: https://www.dolthub.com/blog/2023-11-10-stack-traces-in-go/
The above offers some alternative packages which you may find preferable.
Hopefully that helps, but please let us know if you continue to have any issues.
Describe the bug
Using fmt.Errorf with the %w wrap verb reports "unknown method:0" in the UI.
It looks like this is due to the cause from the Unwrap method on the error.
The response looks like this
Steps to reproduce
Environment
Example code snippet
Error messages:
``` ```