ref(grouping): Increase config transition and move config tests#112508
Merged
lobsterkatie merged 2 commits intomasterfrom Apr 8, 2026
Merged
ref(grouping): Increase config transition and move config tests#112508lobsterkatie merged 2 commits intomasterfrom
lobsterkatie merged 2 commits intomasterfrom
Conversation
github-actions
bot
added
the
Scope: Backend
lobsterkatie
force-pushed
the
kmclb-increase-config-transition-to-90-days
branch
from
45edc0d to
2c492a1
Compare
lobsterkatie
changed the title
shashjar
approved these changes
Apr 8, 2026
Member
shashjar
left a comment
shashjar
left a comment
There was a problem hiding this comment.
very nice, thanks for the thorough explanation in the PR desc
george-sentry
pushed a commit
that referenced
this pull request
Apr 9, 2026
) When a project's grouping config is updated, we put the project in a transition period, during which we calculate the old hash if we don't find the new hash, so we can attach the new hash to the old hash's group (assuming the old hash exists). This prevents grouping configs from creating new groups even though event data hasn't changed. It used to be that during the transition period, we _always_ calculated the old hash in addition to the new hash, even if we'd already linked the new hash to an existing group (if any). Since the vast majority of events come in to existing groups, this meant a ton of wasted calculation, and an unacceptable slow-down during ingest if too many projects were in transition at once. To limit the number of projects transitioning at any one time, we set the transition period to only last a week. Now, however, we limit the double calculation to the first time we see an event from a given group, rather than every time we see an event from that group. Because this theoretically reduced (by multiple orders of magnitude) the extra work a transition would entail, once we made that change, we increased the transition period to a month. We still hadn't seen it in action, though. That changed a few months ago, when we introduced a new grouping config. Sure enough, though there was an initial spike of double calculations (at about 7% of events), it dropped extremely quickly, and within a few hours it was down under 1% of events (and has only continued to fall since). Even more encouragingly, there was no noticeable change to average ingest time. Now that we have that assurance, we can increase the transition period to the full 90 days it takes for groups to age out, thus preventing even the few groups which go more than a month between events from being recreated. This PR does just that, by changing the `SENTRY_GROUPING_CONFIG_TRANSITION_DURATION` constant. While we're dealing with grouping config stuff, it also moves the relevant tests to their own file, continuing the effort to have `test_event_manager_grouping.py` not be literally a thousand lines long.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a project's grouping config is updated, we put the project in a transition period, during which we calculate the old hash if we don't find the new hash, so we can attach the new hash to the old hash's group (assuming the old hash exists). This prevents grouping configs from creating new groups even though event data hasn't changed.
It used to be that during the transition period, we always calculated the old hash in addition to the new hash, even if we'd already linked the new hash to an existing group (if any). Since the vast majority of events come in to existing groups, this meant a ton of wasted calculation, and an unacceptable slow-down during ingest if too many projects were in transition at once. To limit the number of projects transitioning at any one time, we set the transition period to only last a week.
Now, however, we limit the double calculation to the first time we see an event from a given group, rather than every time we see an event from that group. Because this theoretically reduced (by multiple orders of magnitude) the extra work a transition would entail, once we made that change, we increased the transition period to a month. We still hadn't seen it in action, though.
That changed a few months ago, when we introduced a new grouping config. Sure enough, though there was an initial spike of double calculations (at about 7% of events), it dropped extremely quickly, and within a few hours it was down under 1% of events (and has only continued to fall since). Even more encouragingly, there was no noticeable change to average ingest time.
Now that we have that assurance, we can increase the transition period to the full 90 days it takes for groups to age out, thus preventing even the few groups which go more than a month between events from being recreated. This PR does just that, by changing the
SENTRY_GROUPING_CONFIG_TRANSITION_DURATIONconstant. While we're dealing with grouping config stuff, it also moves the relevant tests to their own file, continuing the effort to havetest_event_manager_grouping.pynot be literally a thousand lines long.