14.2 Grouping rules ¶
Grouping rules determine how similar errors are grouped together in Telebugs. This helps reduce noise and makes it easier to focus on unique issues. Telebugs uses a fingerprinting mechanism similar to Sentry’s, where events with matching fingerprints (e.g., based on backtrace or custom rules) are aggregated into a single issue.
In Telebugs, the grouping process starts by checking for a custom fingerprint
provided via the SDK. If present, it computes the fingerprint by hashing the
custom value (or joined array values separated by "|"). If no custom fingerprint
is set, Telebugs generates a default fingerprint by hashing a "group string"
derived from the event data in this order of priority:
- Backtrace (stack trace): If a stack trace is available in exceptions or threads, the group string is built from relevant frames, preferring "in-app" frames (application code) over system frames. For each frame, it concatenates the filename, function name, and line number. This ensures errors with similar application code paths are grouped, ignoring unrelated differences.
- Exception: If no stack trace exists but exception data is present, the group string combines the exception type (e.g., "TypeError") and value (e.g., "Cannot read property ’x’ of undefined").
- Message: As a fallback, it uses the log entry message or formatted message, grouping based on the error description.
This hierarchical approach mirrors Sentry’s default strategies, focusing on stack traces for precision, falling back to exceptions or messages when needed. For example, two exceptions with identical application stack traces but different system frames would share the same fingerprint and group together.
Grouping details, accessible via a square stack icon in error reports, show the
fingerprint (e.g., a hash like 7bcb86ee6ce64c0a8d0f37fde2ff18c), method
(e.g., "backtrace"), specific frames, message, and merged errors.
