Grouping
The same stack is one issue.
TraceHawk does not open a new issue for every event. The fingerprint is the exception type plus the top application frames. Line numbers and the query string are not part of it.
What is hashed
Each event carries an exception type and a stack. Frames from your application are preferred. If none are marked as application code, the first frames of the stack are used instead. The fingerprint is a hash of the type plus at most three frames. Each frame is stored as function@file.
The file has the query string removed and, for a URL, the origin removed. The line number is not included. A bug that moves from line 40 to line 44 stays the same issue. A second visit increments the event count. A user id you attached is counted once for that issue.
A different function, or a different file, is a different issue. TypeError in readTotal@/js/cart.js does not merge with TypeError in handleCheckout@/js/checkout.js when those are the frames being hashed.
What counts as your code
The PHP client marks frames under /vendor/ and the SDK file as library code. A browser frame is treated as library code when the filename contains node_modules, /vendor/, webpack/bootstrap, <anonymous>, or extensions/. Those frames are skipped while an application frame is available. They are used only when the stack has nothing else.
Releases and regressions
The first event stores the release that was sent with it. Later events update the last-seen release. Resolving the issue takes it off the unresolved list. If another event with the same fingerprint arrives, the issue becomes unresolved again and the activity log records a regression. It is not a new issue. A Jira rule can open another task for that regression when you left that option on.
What does not split an issue
- A new line number in the same function and file.
- A query string change on the same path. /checkout?step=card and /checkout?step=address share the file portion used in the hash.
- The browser origin in a stack URL. https://shop.example/js/cart.js and a later host with the same path hash as the same file.
- Which client sent it. A JavaScript event and a PHP exception only merge when the type and frames actually match, which they usually do not.
What does open a new issue
- A different exception type.
- A different function or file in the top application frames.
- A fresh hashed filename on every deploy, such as app.abc123.js one day and app.def456.js the next. The filename is part of the hash, so the issue splits. A stable release name does not prevent that. The release is stored on the issue. It is not the fingerprint.
Troubleshooting
- One bug looks like many issues after a frontend deploy. The built filename changed. Source maps are not applied. The fingerprint uses the filename the browser sent.
- Library frames are the whole stack, so two different bugs inside a minified bundle can collapse together, or one bug can split, depending on the three frames that were hashed.
- The count on the issue is every event. The count in a Jira rule is only the events inside that rule's window.
Questions
Do line number changes create a new issue?
No. The fingerprint uses the exception type and function@file for up to three application frames. The line number is not included.
Does the query string create a new issue?
No. The query string is stripped from the filename before the hash, and a browser origin is stripped too.
What happens when a resolved issue comes back?
The same issue is opened again and marked as a regression. It does not get a new short id. A Jira rule can file another task if it is set to open one after a regression.
Are users counted once?
A user id attached to the event is remembered on the issue. The same id does not increase the user total again.