update_issue: resolve in a specific / current semver release #1262

Summary

Expose Sentry’s Resolved in release options on update_issue, matching the issue-details dropdown:

• The current semver release (e.g. 0.1.32)
• Another existing release (statusDetails.inRelease)
• The next release (already covered by status='resolvedInNextRelease')

Today status='resolved' is a generic resolve. Any later event from an older still-live build (e.g. 0.1.31 while 0.1.32 is the intended fix) immediately marks the issue regressed. Agents cannot perform the UI action that avoids that.

Related: #878 / #903 already taught update_issue to pass richer statusDetails for ignore. Resolve-in-release needs the same for inRelease.

Sentry UI docs: https://docs.sentry.io/product/releases/

Problem

update_issue status enum is:

• resolved
• resolvedInNextRelease
• unresolved
• ignored

There is no parameter for statusDetails.inRelease.

Mobile / store apps commonly ship a fix in version N while version N-1 is still in the used. The intended triage is:

Resolve in current semver N. Events from N-1 must not regress. Events from N or newer should regress if the error is still present.

Generic resolved does the opposite: the next N-1 event reopens the issue.

resolvedInNextRelease is also the wrong substitute when N already exists in Sentry as a release (the “next” release is then N+1).

Proposed API

Keep resolved as generic resolve. Add optional release targeting, for example:

update_issue({
  organizationSlug: "my-org",
  issueId: "PROJECT-123",
  status: "resolved",
  inRelease: "0.1.32", // or "latest" / full version `package@version+build`
})

That should PUT the same body the UI uses:

{
  "status": "resolved",
  "statusDetails": {
    "inRelease": "0.1.32"
  }
}

Nice-to-have: inRelease: "latest" to match Sentry’s validator (latest → current release), so agents can map “current semver release” without guessing the version string.

Why not only resolvedInNextRelease

That maps to The next release, not The current semver release. When the fix version is already created in Sentry, “next” skips it.

Scope

• event:write (already required by update_issue)
• Return statusDetails in the tool response so agents can confirm inRelease actually stuck
• If the version is not a known release, surface Sentry’s Unable to find a release with the given version error rather than falling back to generic resolve