Replies: 1 comment
-
As discussed in today's SIG meeting, I think this is a great opportunity to create an exception event definition in the semantic convention. This would allow us to avoid the serialization/deserialization required to deal with the ID map, but instead create a well-defined event with well-defined and strongly-typed body fields. Also, errors are point-in-time, just like events. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We were exploring a feature for error instrumentation to support symbolication
As most javascript bundles come in minified files, Error stacks will also report errors with lines/cols relative to the minified js files
We could use source maps of the minified files to be able to map the lines / cols to the original file
But as the app version changes in releases, we need to add the corresponding source map and identifying the correct source map for the minified file becomes a challenge
To address the challenge of identifying the source map as the app changes, we can use
an identifier for the minified file (debug_id by Sentry, https://sentry.engineering/blog/the-case-for-debug-ids) which can be injected in some way into the minified file
We then can add a new attribute to errors to report a map of the minified files with their debug id (stringified as a map is not supported as a span attribute)
We want to suggest a name for this indentifier , source_map_id instead of debug_id for better clarity
We also suggest using exception.source_map_ids as the attribute for the error span
Beta Was this translation helpful? Give feedback.
All reactions