Using fmt.Errorf with the %w wrap verb reports "unknown method:0" in the UI

[emosbaugh]

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

    "exceptions": [
        {
            "error_class": "*fmt.wrapError",
            "message": "failed to do request: TESTING",
            "type": null,
            "stacktrace": [
                {
                    "column_number": null,
                    "in_project": null,
                    "line_number": 87,
                    "method": "myMethod.func1",
                    "file": "github.com/emosbaugh/testing/pkg/testing.go",
                    "type": null,
                    "code": null,
                    "code_file": null,
                    "address_offset": null,
                    "macho_uuid": null,
                    "relative_address": null,
                    "frame_address": null,
                    "source_control_link": null,
                    "source_control_name": "",
                    "macho_file": null
                }
            ],
            "registers": null
        },
        {
            "error_class": "*errors.errorString",
            "message": "TESTING",
            "type": null,
            "stacktrace": [
                {
                    "column_number": null,
                    "in_project": null,
                    "line_number": 0,
                    "method": "unknown method",
                    "file": "unknown file",
                    "type": null,
                    "code": null,
                    "code_file": null,
                    "address_offset": null,
                    "macho_uuid": null,
                    "relative_address": null,
                    "frame_address": null,
                    "source_control_link": null,
                    "source_control_name": "",
                    "macho_file": null
                }
            ],
            "registers": null
        }
    ]

Steps to reproduce

bugsnag.Notify(fmt.Errorf("TESTING %w", errors.New("TESTING")), bugsnag.SeverityError)

Environment

• Bugsnag Go version:
• Go version: 1.20
• Integration framework version:
  • Martini:
  • Negroni:
  • net/http:
  • Revel:
  • Other: other

Example code snippet

bugsnag.Notify(fmt.Errorf("TESTING %w", errors.New("TESTING")), bugsnag.SeverityError)

Error messages:

``` ```

[mclack]

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.

[emosbaugh]

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

[clr182]

Hi @emosbaugh We are currently investigating this issue and will reach out once we have more information to share.

[emosbaugh]

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: @.***>

[clr182]

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.

[emosbaugh]

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

[mclack]

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.