getsentry / getsentry/sentry

[grouping] Separate calls to rust enhancer

Open
#84,824 0 comments 0 reactions 1 assignee Claimed by @lobsterkatie View on GitHub
Improvement
Dominant language
Python
Stars
44.8k
Forks
4.9k
Avg merge
22h 21m
Merged PRs (30d)
586

Description

While working on https://github.com/getsentry/sentry/issues/83603, it became clear that the current way we use the rust enhancer during grouping doesn't work.

**Background**

We want the precedence order of `in-app` decisions to be (from highest to lowest):

- Stacktrace rules set by the user on the server
- `in-app` values set by the user in the client
- Event-specific rules created by us on the server
- Project-specific rules created by us on the server
- Generic rules from the grouping config
- A default value of false if the value hasn't been set by any of the above

Event- and project-specific rules are a new thing and haven't yet been implemented, but even without them, we still want it to go custom stacktrace rules, then custom client values, then generic stacktrace rules, then the default.

The problem is, we currently jam custom rules and generic rules together into a giant text blob and pass the whole thing to the rust enhancer, leaving us with effectively no way to know whether an `in-app` value it sets comes from us (in which case a custom value from the client should overrule it) or from the user (in which case it shouldn't). This is why we currently (incorrectly) allow `in-app` values from our generic rules to override values the user has set in the client.

**Fix**

The fix to this is to pass customer rules and our generic rules to the rust enhancer separately. That way, we know the source of any decision, and can correctly prioritize it (or not).

**Bonus side effect**

Right now, we allow custom stacktrace rules to override generic stacktrace rules by first applying the generic ones and then applying custom ones, such that custom values overwrite generic ones. What this means is that we take the time to check all 300 or so of our rules, even in cases where our decision is overridden.

Once we separate the calls to rust, we'll be able to first apply custom rules, and then only bother with the generic rules if the custom rules haven't provided a result (in other words, short-circuit the process), which should provide at least modest performance gains.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.