You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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):in-app
values set by the user in the clientEvent- 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) allowin-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.
The text was updated successfully, but these errors were encountered: