Closed bradleyayers closed 1 year ago
No, sorry, that seems more of a problem with your monitoring than with our errors. Changing them like this will make them harder to read (you won't see the position in your crash/stack trace).
I feel like it should be possible to fish out the error constructor call line from the stack trace and use that as a key.
That makes sense, I'll investigate that. https://docs.sentry.io/product/data-management-settings/event-grouping/fingerprint-rules/#errorvalue looks viable
To preface, we have a set of patches that I'd like to try and upstream.
We use Sentry to monitor unhandled errors, and we find that errors with dynamic messages can be problematic as they are seen as "different problems" rather than "different instances of the same problem". The way we've solved this is to make error messages stable, and put dynamic values as properties on the error, for example here's a patch to prosemirror-model:
We have quite a number of these, is there appetite for having these merged?