Release re-open logic doesn't account for branch lineage

Sentry re-opens resolved issues based on release ordering (semver or creation date), with no awareness of VCS branch lineage. In multi-stream or multi-branch workflows, a newer-by-date release may not contain a fix from a parallel branch, producing false regressions.

Current behavior

• Releases are ordered by semver or creation date; re-open fires when an event arrives from a "newer" release by that ordering
• "Resolved in a commit" waits for the fix commit to appear in any release, then reverts to version/date comparison for subsequent events — it does not continue checking commit membership per release
• Issue resolved/regressed state is global to the issue group; environments scope filtering and alerts but do not partition resolution state

Gap
In branching workflows (e.g., a fix lands in main but a release branch forked before the fix and its next build is dated later), Sentry re-opens the issue for the release-branch build even though the fix was never merged there. There is no mechanism to express "fixed in branch X, not yet in branch Y."

This affects any team using long-lived parallel release branches — common in Perforce stream-based workflows, Git release branches, or monorepo lane builds.

Workarounds today

• Separate Sentry projects per stream/branch (full isolation, but requires manual cross-stream correlation)
• Build-system-driven API state management, where the build system asserts which commits a release contains (correct but complex)
• Archive-with-condition instead of resolve, decoupling suppression from release ordering

Options

• Make "resolved in a commit" check commit membership for every future event, not just until the first matching release — re-open only if the fix commit is absent from the event's release commit list
• Per-project or per-environment resolution state, letting teams resolve independently per stream
• Release lineage/parent metadata so Sentry can infer whether a release descends from the resolved release before firing a re-open

References

• https://docs.sentry.io/product/releases/
• https://docs.sentry.io/product/releases/associate-commits/
• https://docs.sentry.io/integrations/source-code-mgmt/perforce/

Start with the referenced release and associate-commits documentation, then review the current release-ordering and commit-membership behavior described in the issue. Before implementation, establish which proposed option is intended and define done as branch-aware re-open behavior with coverage for parallel release streams.