Skip to content

Pino integration strips error objects #17981

Closed

Description

@InterstellarStella

Is there an existing issue for this?

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.

Activity

  1. linear commented on Oct 21, 2025

    @linear
  2. moved this to Waiting for: Product Owner in GitHub Issues with 👀 3on Oct 21, 2025
  3. andreiborza commented on Oct 21, 2025

    @andreiborza
    Member

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

  4. moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3on Oct 21, 2025
  5. AbhiPrasad commented on Oct 21, 2025

    @AbhiPrasad
    Contributor

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

  6. timfish commented on Oct 21, 2025

    @timfish
    Collaborator

    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?

  7. github-actions commented on Oct 24, 2025

    @github-actions
    Contributor

    A PR closing this issue has just been released 🚀

    This issue was referenced by PR #17999, which was included in the 10.22.0 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions