Grouping Investigations

[brianthi]

• Potential Grouping Issues: Review user reported grouping problems #49584
• Groups without stacktraces: Investigate platform specific problems when no stacktrace available #49585

[armenzg]

NOTES:

• It would be ideal that Sentry by default set a field of what URL was attempted and the status code. This would be incredibly powerful because it would allow filtering and grouping issues based on domain or status code

Some notes from Slack:

The advantage of rules like error.type:ApiHostError -> api-host-error, {{ transaction }} is that when a host is not available we only get 1 group per transaction rather than N groups per transaction (N being the number of distinct API calls to that host).

Since I removed the rule, you can see that we’re getting more than 1 group per transaction (see screenshot).

The screenshot below shows that both process_commit_context and the derive_code_mappings tasks created many groups when api.github.com had a blip. This is because their stack traces had different API calls coming from different parts of the code.

IIUC It all comes from a call to a socket’s connect that fails (link to code)

Should we consider grouping certain network calls based on their transaction or module?

Perhaps in the UI, we give a setting to customers to choose if to NOT group certain network calls.

Perhaps this is a TSC topic or bad idea right away.

[armenzg]

Filed and it won't be fixed due to the large amount of work.

The context-line changes, thus, it creates a new group.
Perhaps, we can suggest grouping for this new group with the old one.

NOTE: I grouped them already by hand.

This code landed and it changed the line where the error is produced.

The error used come from for user in get_suspect_commit_users(project, event) but now it comes from get_suspect_commit_users(project, event):

See how the context-line changes:

• Link to query
• Link to old event (old group redirects)
• Link to new issue

[armenzg]

There's a Django project (project_id=4149647787) (filed) that uses captureMessage instead of captureException, thus, errors are being grouped by message, thus, UUIDs in the message produce different groups.

The Electron SDK (filed) includes the user paths in the module for stack traces, thus, generating groups per user.

---

[armenzg]

create a way to see number of groups per platform across orgs (filed).

[armenzg]

Arpad mentioned that this may not be a valid grouping issue:

getsentry/sentry-rust#582

When working with Rust issues, can we make it default to unwind to the panic and group by that as opposed to grouping by the exception?

[armenzg]

Everything in this issue has been tracked internally as part of the project.