We’ve released an updated to how Javascript errors are grouped in Rollbar. The new update does a better job of separating different errors into different groups (“Items” in Rollbar parlance) while still recognizing the same issue in different browsers as the same. It’s now enabled for all new projects. Existing projects can enable it on the Migrations tab in Settings.
Now the longer version…
First some background: by default, exceptions in Rollbar are grouped using their stack traces. We take all of the filenames and method names in all of the stack frames, plus the exception class name, apply a number of heuristics to normalize them, and then combine everything together and take a sha1 hash. The result is a 40-character string used as the “fingerprint”; occurrences with matching fingerprints that also have the same project, environment, and platform are grouped together. The fingerprint can also be overridden at the API level for custom grouping.
This generally works pretty well:
- Omitting the line numbers from stack frames means groups persist across code changes elsewhere in the file.
- Using the whole stack trace, instead of just the very last frame, avoids conflating unrelated issues that happen to cause an exception on the same line of code.
- Using just the exception class, instead of also the message, avoids including data in the fingerprint, and when we have a nice, long stack trace, that’s usually enough uniqueness.
Javascript uncaught errors are a different story though. They’re reported through window.onerror, which luckily is supported in all major browsers but doesn’t provide a lot of context: only the error message, filename, and line number. The Rollbar javascript library converts this into a stack trace with a single frame (using the filename and line number), and parses the error message to get a semblance of class and message.
The problem with this approach has been that since the grouping algorithm only uses filenames (not line numbers), there’s only one stack frame, since it only uses the exception class name (not message), there isn’t a whole lot of uniqueness. The updated algorithm improves this dramatically.
Here’s how it works:
- There aren’t that many different kinds of Javascript errors. We’ve built up a database of the error messages generated by all of them, in all major browsers.
- When we process an error, we try to match it against the patterns we know about. Several of the patterns have data in them; for some of the patterns, we keep the data (i.e. if it’s a variable name), and in others we discard it (i.e. if it’s an out-of-range precision value).
- If we aren’t able to match any of the known patterns, we fall back to the old algorithm.
We’ve been using this internally for the past couple weeks and so far it feels much better. A caveat: our pattern database currently is English-only, so errors from end-users with their language preferences set otherwise will be grouped using the old algorithm.
The new algorithm is now enabled for all newly-created projects. We aren’t automatically turning it on for old projects because none of the new groups will map to old groups; this will be a one-time event but could result in a lot of notifications and we don’t want to force the change. To enable it for an existing project, find the Migrations tab in the Settings for your project, and check the box next to “Browser JS Occurrence Grouping V2”.
Any questions? Let us know in the comments.
Rollbar collects and analyzes errors so you can find and fix them faster.
Create a free account to get started today.
