Sentry's resolve-by-commit (a Fixes <SHORT-ID> trailer in the fix commit, releases created with sentry-cli releases set-commits) marks the issue set_resolved_in_release in the FIRST release whose commit range contains the trailer commit. In a master-autodeploys-staging setup, that first containing release is a stage/CI build SHA, not the later production promotion SHA.
Observed end-to-end (2026-09-15, first proven web auto-resolution in our org): fix commit merged to master at ~01:28Z -> first master frontend build registered as a release at ~01:51Z -> Sentry activity shows referenced_in_commit then set_resolved_in_release <stage-build-sha> minutes later. Production promoted a different, later SHA hours afterward.
Two triage-grading consequences:
statusDetails.inReleaseshowing a SHA that never served production traffic is NOT a mistargeted resolution — verify withgit merge-base --is-ancestor <fix> <inRelease>instead of matching against the prod deploy SHA.- The auto-resolve timestamp is NOT the fix-live boundary. Acceptance windows ("no events since the fix shipped") must date from the production promotion, because prod events between auto-resolve and promotion are pre-fix traffic and will (correctly) reopen the issue as a regression that isn't one.
Related trap on the manual side: update --in-next-release means the next release after the issue's LAST OBSERVED release in date order, which may already exist and may predate the fix; the commit-trailer path supersedes such a bad resolution correctly once the issue reopens.