Pr 101615 #101658
Pr 101615 #101658
Conversation
github-actions
bot
added
the
Scope: Backend
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
![seer-by-sentry[bot]](https://avatars.githubusercontent.com/in/801464?s=60&v=4){kind=small}
| else: | ||
| new_status_details["inFutureRelease"] = future_release_version | ||
| res_type = GroupResolution.Type.in_future_release | ||
| res_type_str = "in_future_release" | ||
| res_status = GroupResolution.Status.pending | ||
|
|
||
| # Pass placeholder release to process_group_resolution | ||
| release = release_placeholder | ||
|
|
||
| # Leave activity_data["version"] as "" | ||
| # and set activity_data["future_release_version"] in process_group_resolution |
There was a problem hiding this comment.
Potential bug: When resolving an issue in a future release that doesn't exist, activity_data is not initialized, causing a NameError in process_group_resolution.
-
Description: When resolving an issue with a status of
resolvedInFutureReleasefor a release that does not yet exist, thereleasevariable isNone. This directs control flow to anelseblock where theactivity_datavariable is never initialized. Later, this uninitialized variable is passed as an argument to theprocess_group_resolutionfunction, which will raise aNameError. This failure occurs during a primary use case for the feature, which is resolving an issue against a future, non-existent release version. -
Suggested fix: Initialize
activity_datato an empty dictionary within theelseblock that handles future releases that do not yet exist. For example, addactivity_data = {}at the beginning of the block, similar to how other resolution paths handle this variable.
severity: 0.9, confidence: 0.98
Did we get this right? 👍 / 👎 to inform future reviews.
Dashboard-User-Id: 56238550-c99b-43c7-916d-956ef2e03a51
| "version_raw" | ||
| ) | ||
| release_raw = parse_release(release.version, json_loads=orjson.loads).get("version_raw") | ||
| return compare_version_relay(future_release_raw, release_raw) > 0 |
There was a problem hiding this comment.
Bug: Inconsistent Error Handling in Version Parsing
The clear_future_release_resolutions function calls parse_release on release.version without handling RelayError. While is_semver_version is checked, parse_release can still fail for malformed semver strings, potentially crashing the task. This contrasts with the future_release_version parsing in the same function, which includes error handling.
Additional Locations (1)
|
This pull request has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you add the label "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
2 participants
Legal Boilerplate
Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.