The ExtraErrorData integration is not capturing nested error causes

[michaelschufi]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nextjs

SDK Version

8.51.0

Framework Version

Next 15.1.3

Link to Sentry event

https://sally-and-friends.sentry.io/issues/6215894150/events/2b86efb54ff54674bac3bd0582bc1952/

Reproduction Example/SDK Setup

// sentry.server.config (same for the other two)

Sentry.init({
  integrations: [
    Sentry.extraErrorDataIntegration({
      depth: 15,
    }),
  ],
  normalizeDepth: 15,
});

// my custom error class' toJSON

export class CustomError extends Error {
  // ... tell me if you need the whole class. But the point is, that this.cause is returned inside `toJSON`

  toJSON(): Record<string, unknown> {
    return {
      message: this.message,
      name: this.name,
      cause: this.cause,
    };
  }
}

Steps to Reproduce

1. Set up a custom error class that has a toJSON method, which includes the this.cause property.
2. Throw an error which has such error in its cause. E.g.

   throw new TRPCError("Top-level error", {
     cause: new CustomError("Nested error", {
       foo: "bar"
     })
   })

Expected Result

The top-level error is getting serialized, including the extra error data.
The cause field is another structured error data. E.g.

{
  message: "Nested error",
  name: "Custom Error",
  cause: {foo: "bar"},
}

because capturing the cause is enabled by default.

Actual Result

The nested error getting serialized in the format `${errorClassName}: ${message} instead of the whole structured data.

[andreiborza]

Hi @michaelschufi, thanks for filing this.

I just tested this out and had a look at our code, indeed if cause is an Error or if a value of a property inside the JSON returned from toJSON is an Error it gets immediately serialized via toString regardless of having a toJSON itself.

This is something we can consider changing, I'll bring it up with the team. Otherwise, we also welcome contributions if you're interested.

[michaelschufi]

Thanks for the quick response @andreiborza. Sounds good!

I fully expected the integration to walk through all the attributes up to the defined depth - and with captureErrorCause enabled, including the causes of all errors also being serialized.

Also, I want to mention that sometimes there's an error in the error stack that we have no control over (e.g. from a framework TRPCError for example). This error still might have an attribute like originalError or cause, letting us access our CustomError that holds important information about the context the exception occurred. But it does not have a toJSON method. It would be great if attributes of such errors, most importantly the cause, still can get walked through to actually reach the error with the most important context.

Edit: Regarding contributions - I'm not sure how, but I'm happy to assist.

[andreiborza]

Thanks, we'll take a look at that too.

[andreiborza]

@michaelschufi just a heads up, this is very low prio for us atm. I put it in the backlog but we might not get around to it in a while. We don't even have a good idea of how this should work tbh.