Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[grouping] Separate calls to rust enhancer #84824

Open
lobsterkatie opened this issue Feb 7, 2025 · 0 comments
Open

[grouping] Separate calls to rust enhancer #84824

lobsterkatie opened this issue Feb 7, 2025 · 0 comments

Comments

@lobsterkatie
Copy link
Member

lobsterkatie commented Feb 7, 2025

While working on #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant