Developer pages

Issues fingerprinting

How computeFingerprint groups runtime errors into Issues — deterministic rules from ingest.

Fingerprint

A fingerprint is a deterministic SHA-1 grouping key meaning “this is the same bug.” Many raw error events upsert into one Issue row per (project_id, fingerprint).

Runtime errors are fingerprinted on the ingestion server in computeFingerprint after source-map symbolication, so minified frames are normalized to original paths when maps exist.

Runtime algorithm (shipped)

Inputs: exceptionType, value (message), and stackFrames from the SDK error report.

  1. Prefer in-app frames (exclude node_modules, browser extensions, and /humanbehavior*.js SDK files when possible).
  2. Take up to 5 frames.
  3. For each frame, key function@normalizedFileline and column are ignored so small deploys do not split groups.
  4. Basis = exceptionType + those frame keys; fingerprint = sha1(basis).
  5. If no usable frames: basis = exceptionType|normalizedMessage(value) (ids/hex/numbers collapsed).

File normalization

normalizeFile:

  • Strips query/hash and URL origin → pathname
  • Replaces UUIDs, long hex runs, and digit runs with *

Message normalization (no-stack fallback)

normalizeMessage collapses UUIDs, hex literals, and digits so "User 12 not found" and "User 99 not found" group together.

Title & culprit

Separately from the fingerprint, ingest derives:

FieldRule
TitleType: message (truncated) for the Issues list
CulpritTop in-app frame function (file:line) when available

What improves grouping / readability

PracticeWhy
Upload source maps with matching release/distFingerprint keys on original files
Stable release tagsReleases UI + regressions stay coherent
Avoid noisy third-party-only stacks when possibleAll-third-party stacks still group, but on vendor frames

Other issue origins

Fingerprinting above is for runtime crashes (POST /api/ingestion/errors). The Issues product also clusters:

OriginGrouping idea (high level)
BehavioralFrustration signals from replay/trace compile
VisualValue-free DOM-structure fingerprints from session states
StaticRepo-scan findings with their own deterministic fingerprint

Those pipelines share the Issues UX but not the same computeFingerprint function as runtime errors.

What creates a “new” Issue

A new fingerprint — typically a different exception type, different top frames after normalization, or a different normalized message when stacks are absent. Pure line-number shifts alone should not split a group.