Repository navigation
feat(mcp): Resolve issues in a release or commit with update_issue - #2098
Merged
Merged
Conversation
Add optional inRelease, inCommit, and inCommitRepository params to update_issue and send them as statusDetails, matching what the Sentry issue update API already accepts. Co-Authored-By: Bruno Garcia <1633368+bruno-garcia@users.noreply.github.com>
Sentry does not change the resolution of an issue that is already resolved, so report updated=false with the current status instead of raising an input error. Co-Authored-By: Bruno Garcia <1633368+bruno-garcia@users.noreply.github.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Sentry skips groups that are already resolved, so asking update_issue to resolve one in a different release or commit silently did nothing. That includes moving a resolvedInNextRelease issue to the release that shipped. Return an input error that says to unresolve first, as the tool already does for ignore mode switches. A matching resolution is still a no-op. Derive IssueResolutionDetails and the CLI's ResolveStatusDetails from the @sentry/api issue update body instead of hand-writing the shape. Co-Authored-By: BYK <126780+BYK@users.noreply.github.com>
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.
Reviewed by Cursor Bugbot for commit 7dd39df. Configure here.
Once a release contains the resolving commit, Sentry reports the issue as resolved in that release and the issue details drop the commit. A retry of the same inCommit then looked like a different resolution and update_issue threw. For an inCommit request on an issue resolved in a release, read the newest resolve activity and treat the request as already applied when it is set_resolved_in_commit for the same SHA.
BYK
approved these changes
Nov 10, 2026
This branch was successfully deployed
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
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.
update_issuecould only resolve an issue now (resolved) or in the next release (resolvedInNextRelease). Agents that found the release that shipped a fix (for example withfind_releases) had no way to resolve the issue in that release. A plainresolvedlets events from older releases reopen the issue as a regression, and next release is wrong once the fix has shipped. The Sentry issue update API andsentry issue resolve --inalready support this; only the MCP tool was missing it.This adds optional
inRelease,inCommit, andinCommitRepositoryparams. Withstatus='resolved', they are sent asstatusDetails.inReleaseorstatusDetails.inCommit({commit, repository}), whichStatusDetailsValidator/InCommitValidatorin getsentry/sentry accept. The payload type is derived from the@sentry/apiissue update body, and the CLI'sResolveStatusDetailsnow derives from it too instead of hand-writing the same shape.Behavior notes:
resolvedInReleaseandresolvedInCommitas status values, next to the existingresolvedInNextRelease, and theeffectnames the release or commit. A commit that is already in a release comes back from Sentry as an in-release resolution, so the tool reports it that way.handle_resolve_in_releaseskips groups that are already resolved. So resolving an issue in the release or commit it is already resolved in is a no-op (updated: false, no PUT). Asking for a different release or commit on a resolved issue, including aresolvedInNextReleaseone, returns an input error that says to setstatus='unresolved'first, the same way the tool handles switching ignore modes. Before this, that request returned a silentupdated: false.inRelease. For aninCommitrequest on such an issue, the tool reads the newest resolve activity and treats aset_resolved_in_commitfor the same SHA as already applied, so retries stay idempotent.update_issue's description had about 110 characters left under the 2048 limit, so the tool description gets one short hint and the param descriptions carry the details.Source: user feedback MCP-SERVER-GKR.
via @bruno-garcia, @BYK.
--
View Session in Sentry