You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
Activity
linear commentedon Oct 21, 2025
JS-1073
andreiborza commentedon Oct 21, 2025
@AbhiPrasad could you take a look at this one too please?
AbhiPrasad commentedon Oct 21, 2025
Yeah we should fix this, @timfish could you take a look?
timfish commentedon Oct 21, 2025
This open PR (#17934) actually excludes the
errfrom the attributes entirely.If there is an error message, Pino automatically maps this to the top-level
msgattribute.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?
github-actions commentedon Oct 24, 2025
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.