Pino integration strips error objects

[InterstellarStella]

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/node

SDK Version

10.20.0

Framework Version

Node 24.7.2

Link to Sentry event

No response

Reproduction Example/SDK Setup

Repro app here.

Steps to Reproduce

Just need Node.js. Run pnpm i, add a data source name, and then finally pnpm run start.

Expected Result

The resulting log contains an error key with an object.

Actual Result

The object in the Sentry Web UI is empty.

In Pino's JSON output, the error is properly serialized:

"err": {"type":"Error","message":"This is an error.","stack":"Error: This is an error...."}

But in beforeSendLog (what gets sent to Sentry), the err attribute is empty:

"err": {}

Which means that the error details are being lost during serialization.

It appears that the Sentry Pino integration is intercepting log events before Pino serializes them. At that point, obj.err is still an actual Error instance. When Error objects are later stringified with JSON.stringify(), they become {} because Error properties are non-enumerable in JavaScript.

Additional Context

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.}

[linear]

JS-1073

[andreiborza]

@AbhiPrasad could you take a look at this one too please?

[AbhiPrasad]

Yeah we should fix this, @timfish could you take a look?

[timfish]

This open PR (#17934) actually excludes the err from the attributes entirely.

If there is an error message, Pino automatically maps this to the top-level msg attribute.

Do we want to add the entire error object to the log attributes? The stack here is going to be a full stack string and there will be no sourcemap support here. It might also contain full paths to files which can contain PII.

Should we be capturing stack traces as logs like this?