Skip to content

Conversation

@ha1fstack
Copy link
Contributor

@ha1fstack ha1fstack commented Aug 11, 2025

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

  • If you've added code that should be tested, please add tests.
  • Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

closes #15142

When using ExtraErrorDataIntegration, error.cause serializes with .toString() which is not very informative considering the purpose of the integration.

This PR improves error.cause handling in ExtraErrorDataIntegration by recursing the _extractErrorData for a single cause depth. To match the outer structure and provide more information the cause object is wrapped with [name].

The .toString() serialized data is gone now but if we are using LinkedErrorsIntegration the string message will still be visible.

Since these changes are useful enough, I think more detailed specifications (like cause recursion) could be addressed by future PRs - open to suggestions.

Before:

// error.cause was serialized as: "SyntaxError: bar" { TypeError: { cause: "SyntaxError: bar" // Just toString() output } }

After:

// error.cause now includes full error data extraction { TypeError: { cause: { SyntaxError: { baz: 42, foo: "aaaa...a...", } } } }
Copy link
Member

@s1gr1d s1gr1d left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sounds like a good idea. Thanks for submitting this

@s1gr1d s1gr1d requested a review from Lms24 August 11, 2025 15:17
cursor[bot]

This comment was marked as outdated.

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

Labels

None yet

2 participants