fix(releases): fix release per-project new issues count in UI #101212
+3
−7
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: Frontend
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| release: d.version, | ||
| date: d.dateCreated, | ||
| error_count: d.newGroups ?? 0, | ||
| error_count: d.projects[0]?.newGroups ?? 0, |
There was a problem hiding this comment.
Bug: Inconsistent Null Handling in Project Mapping
The recent update to error_count introduced inconsistent null handling for projects[0]. Within the same object mapping, projects[0] is accessed with a non-null assertion (!) for the project field, but with optional chaining (?.) for error_count. If projects[0] is null, this can lead to a runtime error, despite error_count safely returning 0. This pattern appears in both releasesDrawerTable.tsx and useOrganizationReleases.tsx.
Additional Locations (1)
There was a problem hiding this comment.
This is using the same null handling that was there before, see https://github.com/getsentry/sentry/pull/99555/files#diff-caa257d18a951bc9fff9803f26c900f499065d4303449adc7bbb65eeb5e5829dL97
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.
Previously, we were using release.newGroups to populate the per-project new issues counts for releases. However, this count is the total number of new issues for this release. Here, we instead use release.projects[x].newGroups, which now contains the correct number of new issues for this release in the selected project.
We switch to using release.projects[x].newGroups in the following places: releases index, releases drawer, session health
reverts #99555, which switched from release.projects[x].newGroups to release.newGroups
followup to #101003, which fixed the backend bug when calculating release.projects[x].newGroups
Demo Setup
RELEASE 1.0.0
Project A - 3 total new groups
Project B - 4 total new groups
RELEASE 2.0.0
Project A - 1 total new group
Demo
Before: the new issues counts for each project are all equal to the total number of new issues in that release (eg, 7 new groups for each project in Release 1.0.0 == 2+1+3+1)
Screen.Recording.2025-10-08.at.2.47.53.PM.mov
After: we get the correct per-project new issues counts, even when filtering by project or env or both
Screen.Recording.2025-10-08.at.2.49.45.PM.mov