feat(rum-core): stringify object rejected by a promise #1428
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Solves: #1423
Context
Before this change, if the promise rejection reason was an object:
The RUM agent was capturing the error this way:
Unhandled promise rejection: <object>
. Additionally, none of the properties were included in the error custom properties, making it difficult for users to identify the error's context.There was an exception to that rule. Objects containing a "message" property:
But unfortunately, this is not something that users can always control.
Enhancement
From now onwards, if the rejection reason of a promise is an object (with no message property), then two things will happen:
JSON.stringify
the obj so that the properties will be visible in the error message. This is similar to the native behaviour of browsers like Google Chrome.You can see an example in the screenshots below:
Notes
the behaviour of other types remains unchanged.
<object>
<function>
The "stringify" of the object will fail at least in two circumstances:
If that happens, a fallback will be applied, meaning that the error will be captured as if was being captured before this change.