feat(aci): Create and update open periods when groups are resolved or unresolved

[snigdhas]

This PR adds all the writes to sentry_groupopenperiod to track the open periods as a group is resolved or unresolved. There's a lot of places we change group status (yay) so here's a breakdown of what we're doing in this PR:

Creating open periods

• Create an open period when new groups are created in event_manager._create_group, guaranteeing every group will start with an open period.
• Create an open period when we detect a regression in event_manager._handle_regression. We deal with regressions further downstream in post_process as well, but this is the first spot where the regression is detected and the group is reopened so it makes sense to create a new open period here as well.
• Update the create_group fixture to create an open period so tests mimic this behavior. This method also closes the open period if we call it with create_group(status=GroupStatus.RESOLVED.

Updating open periods

We update an open period in the following ways based on the new status

• GroupStatus.RESOLVED: close the latest open period
• GroupStatus.UNRESOLVED: this one is more nuanced --
  • if the group status is GroupSubStatus.REGRESSED, we do nothing. The regression is handled in event_manager as detailed above.
  • otherwise, this corresponds to a user-triggered unresolve in which case we re-open the latest closed open period.

In both these cases, we expect the open period to already exist. I've added logging to surface if this isn't the case and expect to see these errors until we backfill the table. Once the backfill is complete, any of these logs will indicate a gap in our handling of open periods. A potential interim fix here is to use the Activity to create the missing open period (ad-hoc backfill) so we can update it as expected. We can remove that once the larger backfill is run.

I've added update_group_open_period to group.py to capture all of this logic.

Closing open periods

Group resolution is done either manually (in group_index/update.py process_group_resolution) or via the auto-resolution task. Both these spots use the update_group_open_period helper to update the open period.

Merging/Unmerging groups:

• Merge: I think we can do nothing here since the parent group will continue to have the expected state in open periods
• Unmerge: This one is tricky since we can unmerge a resolved or unresolved group.
  • For unresolved groups, we can use the open period that gets created on group creation without any modifications.
  • For resolved groups, i'm essentially creating a dupe of the resolution open period in the parent group. This could get weird if we use open periods to determine a default graph time range in the future, but we need to have a resolved open period so we can reopen it if the user decides to unresolve it. The alternative would be to immediately resolve the group but we'd have no resolution activity to pair with it and the resolution time would be inaccurate. This seems less ideal.

[codecov]

Codecov Report

Attention: Patch coverage is 92.19512% with 16 lines in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/sentry/tasks/unmerge.py	45.00%	11 Missing ⚠️
src/sentry/models/group.py	78.26%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #88650      +/-   ##
==========================================
+ Coverage   87.72%   87.78%   +0.06%     
==========================================
  Files       10064    10050      -14     
  Lines      569157   570161    +1004     
  Branches    22351    22220     -131     
==========================================
+ Hits       499269   500507    +1238     
+ Misses      69508    69235     -273     
- Partials      380      419      +39     

[snigdhas]

There's a failing test (BulkDeleteQueryTest) with

ForeignKeyViolation('insert or update on table "sentry_groupopenperiod" violates foreign key constraint "sentry_groupopenperi_group_id_f4411413_fk_sentry_gr"
DETAIL:  Key (group_id)=(79) is not present in table "sentry_groupedmessage".\n')
SQL: SET CONSTRAINTS ALL IMMEDIATE

Would the fix be to set db_constraint=False for the group foreign key?

[ceorourke]

mostly lgtm just have a couple questions

[ceorourke]

There's a failing test (BulkDeleteQueryTest) with

ForeignKeyViolation('insert or update on table "sentry_groupopenperiod" violates foreign key constraint "sentry_groupopenperi_group_id_f4411413_fk_sentry_gr"
DETAIL:  Key (group_id)=(79) is not present in table "sentry_groupedmessage".\n')
SQL: SET CONSTRAINTS ALL IMMEDIATE

Would the fix be to set db_constraint=False for the group foreign key?

Is the problem that the test is deleting a group that's referenced as a FK in the group open period model? Would you want to delete the group open period row when that happens? I think you'd need to set that up in the deletions task here (I could be totally off base but that's what I'd look at)

[snigdhas]

I think you'd need to set that up in the deletions task

Ah good point, added it there!

[ceorourke]

lgtm, wouldn't be offended if you wanted another pass by someone else on the team though

[sentry-io]

Suspect Issues

This pull request was deployed and Sentry observed the following issues:

• ‼️ IntegrityError: ExclusionViolation('conflicting key value violates exclusion constraint "exclude_overlapping_start_end"\nDETAIL: Key (group_id, tstzrange(date_started, date_ended, '[)'::text))=(6337725293, ["2025-04-09 22:28:00+00",)) conflicts with existing key (gr... issues.occurrence_consumer View Issue

_{Did you find this useful? React with a 👍 or 👎}