Skip to content

fix(grouping): Stop parameterizing message variable in custom titles#109893

Merged
lobsterkatie merged 3 commits intomasterfrom
kmclb-stop-parameterizing-message-variable-in-custom-titles
Mar 4, 2026
Merged

fix(grouping): Stop parameterizing message variable in custom titles#109893
lobsterkatie merged 3 commits intomasterfrom
kmclb-stop-parameterizing-message-variable-in-custom-titles

Conversation

@lobsterkatie
Copy link
Member

@lobsterkatie lobsterkatie commented Mar 4, 2026

Fingerprint rules can be used not only to affect grouping but also to set custom titles for events, using the same variables as are used for fingerprinting. When the {{ message }} variable appears in a fingerprint, we parameterize the value, as we do in other places where we use the message for grouping. This parameterization is currently over-applied, though, in that it's also happening when the {{ message }} variable is used in custom titles. (We don't parameterize error messages in non-custom titles, so we shouldn't be doing it in custom titles, either.)

This fixes that by adding a new optional parameterize_message parameter to our resolve_fingerprint_variable helper. It defaults to True, so in most places there's no change in behavior, but it allows us to prevent the parameterization when we're calling it from expand_title_template. As can be seen in the snapshot, neither the fingerprint nor the hash changes, but the title now uses the original values from the message.

This is the other half of the fix for #109301. (The first half was done in #109713.)

@github-actions github-actions bot added the Scope: Backend Automatically applied to PRs that change backend components label Mar 4, 2026
@lobsterkatie lobsterkatie marked this pull request as ready for review March 4, 2026 19:22
@lobsterkatie lobsterkatie requested a review from a team as a code owner March 4, 2026 19:22
@lobsterkatie lobsterkatie merged commit 29ed1dc into master Mar 4, 2026
78 checks passed
@lobsterkatie lobsterkatie deleted the kmclb-stop-parameterizing-message-variable-in-custom-titles branch March 4, 2026 20:06
JonasBa pushed a commit that referenced this pull request Mar 5, 2026
…109893)

Fingerprint rules can be used not only to affect grouping but also to set custom titles for events, using the same variables as are used for fingerprinting. When the `{{ message }}` variable appears in a fingerprint, we parameterize the value, as we do in other places where we use the message for grouping. This parameterization is currently over-applied, though, in that it's also happening when the `{{ message }}` variable is used in custom titles. (We don't parameterize error messages in non-custom titles, so we shouldn't be doing it in custom titles, either.)

This fixes that by adding a new optional `parameterize_message` parameter to our `resolve_fingerprint_variable` helper. It defaults to `True`, so in most places there's no change in behavior, but it allows us to prevent the parameterization when we're calling it from `expand_title_template`. As can be seen in the snapshot, neither the fingerprint nor the hash changes, but the title now uses the original values from the message.

This is the other half of the fix for #109301. (The first half was done in #109713.)
lobsterkatie added a commit that referenced this pull request Mar 11, 2026
This is a small refactor to the code used for variable resolution in custom fingerprints. Recently, we began parameterizing the `{{ message }}` variable using `normalize_message_for_grouping` inside of `resolve_fingerprint_variable`[1], but subsequently realized we needed to prevent parameterization when the variable is used for a custom title. Thus we introduced a `parameterize_message` parameter to `resolve_fingerprint_variable`[2], to control whether or not parameterization runs.

This PR is a different (better) solution to the same problem, done in order to both simplify the code and decrease the blast radius of an upcoming change to `normalize_message_for_grouping`. Instead of having `parameterize_message: True` at one of the two `resolve_fingerprint_variable` call sites and `parameterize_message: False` at the other, it just moves the parameterization to the one place where `parameterize_message` is currently true. This lets us get rid of the new parameter, and prevents the `parameterize_message: False` code from having to compensate for the `normalize_message_for_grouping` changes.


[1] #107808
[2] #109893
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Backend Automatically applied to PRs that change backend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants