Skip to content

Conversation

@malwilley
Copy link
Member

@malwilley malwilley commented Dec 17, 2025

Adds a new condition which triggers on the resolution of an issue.

CleanShot 2025-12-17 at 08 49 44

@malwilley malwilley requested a review from saponifi3d December 17, 2025 16:56
@malwilley malwilley requested a review from a team as a code owner December 17, 2025 16:56
@github-actions github-actions bot added the Scope: Backend Automatically applied to PRs that change backend components label Dec 17, 2025
@codecov
Copy link

codecov bot commented Dec 17, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

Additional details and impacted files
@@             Coverage Diff             @@
##           master   #105156      +/-   ##
===========================================
- Coverage   80.72%    80.62%   -0.11%     
===========================================
  Files        9418      9417       -1     
  Lines      406044    403988    -2056     
  Branches    25662     25662              
===========================================
- Hits       327783    325716    -2067     
- Misses      77792     77803      +11     
  Partials      469       469              

group = event_data.group
return group.status == comparison
is_resolved = group.status == GroupStatus.RESOLVED
return is_resolved == comparison
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, i don't think we'll be able to just modify the existing condition. This data is also stored in the DB and would require a migration to change, and i think we'd still need this condition for some legacy alerts as well.

Instead, i was thinking maybe we could just reuse the ISSUE_RESOLUTION_CHANGE condition and hardcode the info, but not sure how we'd be able to tell the difference between them in the UI to show w/o a new condition type now that i think about that...

So instead, I think it'll probably need to be a fully new data condition.

Maybe something like this:

# src/sentry/workflow_engine/handlers/condition/issue_resolved_trigger_condition.py

@condition_handler_registry.register(Condition.ISSUE_RESOLVED_TRIGGER)
class IssueResolvedTriggerCondition(DataConditionHandler[WorkflowEventData]):
    group = DataConditionHandler.Group.WORKFLOW_TRIGGER

    @staticmethod
    def evaluate_value(event_data: WorkflowEventData, _: Any) -> bool:
        group = event_data.group
        return group.status == GroupStatus.RESOLVED

This should also be automatically added to the correct API with the group = DataConditionHandler.Group.WORKFLOW_TRIGGER being set, so it'd just be this file + the new Condition

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm are you sure this condition is in use? I queried for it in the database and couldn't find any instances of it: https://redash.getsentry.net/queries/10176/source

Happy to make a new one as well, just thought that this one was dangling unused

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@saponifi3d ah okay gotcha - added the new data condition and reverted this one

@malwilley malwilley merged commit a222408 into master Jan 8, 2026
67 checks passed
@malwilley malwilley deleted the malwilley/feat/set-up-resolution-condition-for-use-in-ui branch January 8, 2026 21:25
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.

4 participants