fix(releases): Prevent premature issue resolution from commit messages #107138
+260
−48
Conversation
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
github-actions
bot
added
the
Scope: Backend
Member
Author
|
bugbot review |
Member
Author
|
@cursor review |
Member
Author
|
@sentry review |
Issues were being resolved immediately when commits with "Fixes ISSUE-123" were pushed to any branch, including feature branches. This caused issues to be resolved before the fix was actually merged to the main branch. This change modifies `resolved_in_commit()` to only create GroupLinks and Activity entries without immediately resolving issues. Resolution now happens via `update_group_resolutions()` when a release is created that includes the commit, ensuring issues are only resolved when code is actually deployed.
JoshFerge
force-pushed
the
jferg/fix-premature-commit-resolution
branch
from
3849d15 to
2d3afc8
Compare
Member
Author
|
bugbot review |
Member
Author
|
@sentry review |
![sentry[bot]](https://cdn.statically.io/img/avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
![cursor[bot]](https://cdn.statically.io/img/avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Slack/Teams notifications for SET_RESOLVED_IN_COMMIT activities were using ResolvedActivityNotification which says "marked as resolved" (past tense). Since commits no longer immediately resolve issues, this was misleading. Created ResolvedInCommitActivityNotification that says "will resolve" (future tense), matching the behavior of ResolvedInPullRequestActivityNotification.
When a commit with "Fixes ISSUE-123" is pushed, resolved_in_commit() creates a GroupLink without resolving the issue. If a user then tries to resolve via the API using the same commit, the direct create() would fail with IntegrityError. Changed to get_or_create to handle the case where the GroupLink already exists from the signal handler.
The notification now checks group.status to determine the correct message: - If issue is RESOLVED (API path): "marked as resolved in a commit" - If issue is UNRESOLVED (commit push path): "will resolve" This handles both scenarios where SET_RESOLVED_IN_COMMIT activity is created.
Adds a test that verifies the API handles the case where a GroupLink already exists when resolving an issue with inCommit. This scenario occurs when a commit is pushed with "Fixes ISSUE-123" (creating a GroupLink via resolved_in_commit signal) and then the user manually resolves via API with the same commit.
Add `organizations:defer-commit-resolution` feature flag to control whether issues are resolved immediately when commits are pushed (legacy) or deferred until a release is created (new behavior). - Flag ON: Creates GroupLinks and Activity but defers resolution - Flag OFF: Immediately resolves issues (legacy behavior) This allows gradual rollout of the fix for premature issue resolution.
Contributor
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
The test expects deferred resolution behavior, so it needs the organizations:defer-commit-resolution flag enabled.
scttcper
approved these changes
Jan 30, 2026
armenzg
reviewed
Jan 30, 2026
|
|
||
| class FindReferencedGroupsTest(TestCase): | ||
| @with_feature("organizations:defer-commit-resolution") | ||
| def test_resolve_in_commit(self) -> None: |
Member
There was a problem hiding this comment.
Would it make sense to keep a test without the feature until this is shipped?
| # Issue should NOT be resolved immediately - resolution happens via releases | ||
| group.refresh_from_db() | ||
| assert group.status == GroupStatus.RESOLVED | ||
| assert group.status == GroupStatus.UNRESOLVED |
Member
There was a problem hiding this comment.
Should you also test the logic of the when the commit gets merged into the default branch and then become part of a release?
There's also the case scenario when the commit gets squashed into the default branch and the sha changes. Would a new GroupLink be created and use that instead of the first commit with "Fixes" in the description?
armenzg
approved these changes
Jan 30, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
Fixes issue where Sentry issues were being resolved prematurely when commits with "Fixes ISSUE-123" were pushed to feature branches. Issues should only resolve when code is actually merged to the default branch (i.e., when a release is created).
Changes
1. Feature flag for gradual rollout
Added
organizations:defer-commit-resolutionfeature flag to control the behavior:2. Defer commit-based resolution to release creation
Modified
resolved_in_commit()to create GroupLinks, Activity, and GroupHistory entries without immediately resolving issues when the feature flag is enabled. Resolution now happens viaupdate_group_resolutions()when a release is created.issue_resolvedsignal3. Fix Slack/Teams notifications
Created
ResolvedInCommitActivityNotificationthat dynamically chooses the correct message:4. Fix API duplicate GroupLink error
Changed
GroupLink.objects.create()toget_or_create()inprocess_group_resolution(). This prevents IntegrityError when a user manually resolves an issue via the API using a commit that was already linked by the signal handler.Files Changed
src/sentry/features/temporary.py- Addorganizations:defer-commit-resolutionfeature flagsrc/sentry/receivers/releases.py- Add feature flag check and conditional resolution logicsrc/sentry/notifications/notifications/activity/resolved_in_commit.py- New notification class with dynamic messagesrc/sentry/integrations/slack/service.py- Use new notification class for commit activitiessrc/sentry/integrations/msteams/notifications.py- Use new notification class for commit activitiessrc/sentry/api/helpers/group_index/update.py- Useget_or_createfor GroupLinktests/sentry/receivers/test_releases.py- Tests for both flag ON and OFF behaviorsTest plan
Rollout Plan
Known issue (pre-existing, not addressed)
update_group_resolutions()inset_commits.pydoesn't setresolved_attimestamp when resolving via releases. This is a pre-existing bug that affects all release-based resolutions, not introduced by this PR.