A typical pattern on an error page, particularly for a global error handler (like a crash dialog), is to show the user the event ID of the crash.
This is useful both if the user is a customer and wants to report that upstream, but even more so when the user is a developer or member of the project.
The challenge with doing that today, particularly with JavaScript, is errors are plentiful, and the only API we provide is something akin to "getLastEvent". That latest event, even if its an error, it may be the wrong event. As we expand data capture, or you more richly instrument your app, this becomes increasingly likely, and thus this implicit API is a little too brittle.
Solution Brainstorm
I'd prefer to have something like:
Sentry.getEventID(error)
How that works internally could vary. Whether its keeping a buffer of errors and their event IDs, or assigning a property to errors (Error._sentryID).
non-errors being thrown, if you throw an object we create a synthetic error to grab the stacktrace, that synthetic error is not accessible from user land. What should happen in these cases?
this will probably be stored as a weakmap otherwise we risk memory issues, but then what happens when the error gets GC’d? I guess we can make it an fixed-size LRU? Maybe we need different strategies for different runtimes.
this makes it much harder to have an architecture where ids are generated lazily. uuids are expensive in their own way. shouldn’t be that big of a blocker, internals just need to be refactored as such
Problem Statement
A typical pattern on an error page, particularly for a global error handler (like a crash dialog), is to show the user the event ID of the crash.
This is useful both if the user is a customer and wants to report that upstream, but even more so when the user is a developer or member of the project.
The challenge with doing that today, particularly with JavaScript, is errors are plentiful, and the only API we provide is something akin to "getLastEvent". That latest event, even if its an error, it may be the wrong event. As we expand data capture, or you more richly instrument your app, this becomes increasingly likely, and thus this implicit API is a little too brittle.
Solution Brainstorm
I'd prefer to have something like:
How that works internally could vary. Whether its keeping a buffer of errors and their event IDs, or assigning a property to errors (
Error._sentryID
).