Conversation
…itions A release condition value that starts with >, >=, <, <= or = now compiles to Relay's semver rule condition instead of a glob, so a filter can drop data from a version range such as >=1.2.0 without listing each version as a pattern. The API rejects a comparison whose release carries no version, as Relay would never match it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
github-actions
Bot
added
the
Scope: Backend
![sentry-warden[bot]](https://avatars.githubusercontent.com/in/2755838?s=60&v=4){kind=small}
Comment on lines
+137
to
+142
| if attrs["type"] == ConditionType.RELEASE: | ||
| invalid = [ | ||
| value | ||
| for value in attrs["value"] | ||
| if (comparison := parse_release_comparison(value)) | ||
| and not is_release_version(comparison.release) |
Contributor
There was a problem hiding this comment.
Release comparison validation can 500 on RelayError from parse_release
Wrap is_release_version() so parse_release RelayError returns False; otherwise invalid comparison values like >=package@1.0.0-@ crash this serializer with a 500 instead of a 400.
Evidence
- The new RELEASE branch calls
is_release_version(comparison.release)on each user-supplied comparison value. is_release_version()invokessentry_relay.processing.parse_releasewith no try/except.Release.is_semver_version()and other call sites catchRelayErrorfromparse_release("invalid legacy releases") and treat it as non-semver.- An uncaught
RelayErrorhere escapes DRF validation and becomes a 500 instead of the intended validation error.
Identified by Warden · sentry-backend-bugs · FYL-YBT
A release value without a comparator that carries a version, such as 1.2.0 or myapp@1.2.0, now compares as equal to that version instead of matching the text. So 1.2 matches 1.2.0 of every package, and a build code does not get in the way. A value without a version, such as a commit hash or a glob, still matches the text. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Contributor
Backend Test FailuresFailures on
|
shellmayr
changed the title
This branch has not been deployed
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
semverrule condition, added in feat(generic-filters): Add a semver rule condition relay#6430. That is a value with a leading>,>=,<,<=or=, or a plain release with a version such as1.2.0ormyapp@1.2.0, which compares as equal. Any other value stays a glob pattern, so one condition can mix1.*with>=3.0.>2*or<a4b7e0f9c2d1. Relay would never match those, so the filter would silently lose part of its values.semverop reads the condition as unsupported and never matches it. Such a filter drops nothing instead of dropping more than configured.