feat(flags): support semver comparisons in user_blast_radius

[dmarticus]

Problem

We're building SemVer targeting for feature flags, so the first thing we need to do is make sure that the user_blast_radius function can correctly evaluate potential rollouts that have semver operators. This change should be no-op, as we don't support creating flags with semver operators yet, but this is just laying the groundwork, tinkering with some hogQL, and keeping the PR footprint small.

Changes

1. Added 8 new semver operators (frontend/src/types.ts:820-827, posthog/schema.py):
   - semver_eq, semver_gt, semver_gte, semver_lt, semver_lte
   - semver_tilde (~1.2.3 matches >=1.2.3 <1.3.0)
   - semver_caret (^1.2.3 matches >=1.2.3 <2.0.0)
   - semver_wildcard (1.2.* matches >=1.2.0 <1.3.0)
2. Extended HogQL property filtering (posthog/hogql/property.py:273-405):
   - Implemented all 8 operators using the existing sortableSemver function
   - Added proper error handling with QueryError
   - Fixed edge case bug for empty wildcard patterns
3. Added comprehensive tests:
   - Integration tests in posthog/api/test/test_feature_flag.py:8362-8615
   - Unit tests in posthog/hogql/test/test_property.py:1084-1172
   - All 4 semver tests pass (2 unit + 2 integration)
   - All 24 blast radius tests pass
4. Added frontend operator mappings (frontend/src/lib/utils.tsx:332-341):
   - Human-readable labels for all operators

Publish to changelog?

no

[dmarticus]

these changes aren't relevant yet, since we're not making UI changes, but they'll matter soon. They're good to have for all of these schema validation changes.

[dmarticus]

an important thing to note here is that we're using the sortableSemver hogQL function to implement the data extraction, but this method does not support all of valid semver, e.g. things like 1.0.0-alpha.1 aren't supported. I'll make this change in a future PR; just trying to get the broad strokes down here.

[cubic-dev-ai]

1 issue found across 8 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="posthog/hogql/property.py">

<violation number="1" location="posthog/hogql/property.py:343">
P1: Caret operator doesn't handle 0.x.y versions per semver spec. According to semver, `^0.2.3` should mean `>=0.2.3 <0.3.0` (not `<1.0.0`), and `^0.0.3` should mean `>=0.0.3 <0.0.4`. The current implementation always bumps major version, which will cause incorrect feature flag targeting for pre-1.0 software versions.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[haacked]

Nice work!

Some non-blocking comments.

Would like to see more tests of edge cases in order to document what behavior we expect with values like these.

• 0.0.0 - minimal version
• 1.2.3-alpha - We don't support it yet, but want to document what should happen
• v1.2.3
• 1.2.3 - (leading space)
• 1.2.3 - (trailing space)
• 01.02.03 - (Should be same as 1.2.3 even though I believe it violates Semver spec)
• 1.2.3.4 - Too many version numbers. These are common in .NET land though
• 1..2.3 - empty component
• 1.2.3. - trailing dot
• .1.2.3 - leading dot
• 1.-2.3 - negative version part (invalid semver)

[haacked]

We might want to consider 1.0 as 1.0.0 down the road.
Also, if someone does pass 1.0.0-alpha.1 have we already stripped out the -alpha.1 by this point?

[haacked]

This parsing does what I described earlier by treating 1.0 as 1.0.0. Would it make sense to have a standard function to do this parsing and return the parts?

[haacked]

Each of the three range operators (tilde, caret, wildcard) does these 4 steps:

1. Validate input type
2. Parse version parts
3. Calculate bounds
4. Return the same AST structure

Maybe extract that into a helper method?

[haacked]

The range operators all validate the input type:

if not isinstance(value, str):
    raise QueryError("Semver operators require a string value")

Would it make sense to have the basic operators also do this so errors are consistent rather than dependent on whatever sortableSemver does?

[greptile-apps]

_{9 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Greptile's behavior is changing!

From now on, if a review finishes with no comments, we will not post an additional "statistics" comment to confirm that our review found nothing to comment on. However, you can confirm that we reviewed your changes in the status check section.

_{This feature can be toggled off in your Code Review Settings by deselecting "Create a status check for each PR".}

[greptile-apps]

_{9 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

_{9 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

What's Being Changed

The PR introduces comprehensive semver comparison operators that follow the semantic versioning specification:

• Basic operators: semver_eq, semver_neq, semver_gt, semver_gte, semver_lt, semver_lte
• Range operators: semver_tilde (~1.2.3 = >=1.2.3 <1.3.0), semver_caret (^1.2.3 = >=1.2.3 <2.0.0), semver_wildcard (1.2.* = >=1.2.0 <1.3.0)

The changes span multiple layers:

1. Schema updates (frontend/src/queries/schema.json, frontend/src/queries/validators.js): Added new operators to validation schemas
2. Type definitions (frontend/src/types.ts): Extended PropertyOperator enum with semver operators
3. HogQL engine (posthog/hogql/property.py): Core implementation using ClickHouse's sortableSemver function
4. UI mappings (frontend/src/lib/utils.tsx, ee/hogai/summarizers/property_filters.py): Human-readable labels for operators
5. Comprehensive testing (posthog/hogql/test/test_property.py, posthog/api/test/test_feature_flag.py): Unit and integration test coverage

How It Works

The implementation leverages ClickHouse's existing sortableSemver function to convert version strings into comparable formats. Range operators like tilde, caret, and wildcard are converted into bounded AND conditions. For example, ^1.2.3 becomes sortableSemver(property) >= sortableSemver('1.2.3') AND sortableSemver(property) < sortableSemver('2.0.0').

The code includes proper semver parsing with support for pre-release suffixes, missing version components, and follows semver specification edge cases (e.g., ^0.2.3 means >=0.2.3 <0.3.0, not <1.0.0).

Test Coverage

• Unit tests: Validate basic functionality, error handling, and edge cases
• Integration tests: Test all operators through the user_blast_radius API endpoint
• Edge case testing: Covers 0.x.y versions, pre-release suffixes, v-prefixes, whitespace handling

The testing strategy follows the custom rule of preferring parameterized tests where appropriate, with clear documentation of expected behavior.

Potential Issues

⚠️ Schema synchronization risk: Multiple auto-generated schema files were updated (frontend/src/queries/schema.json, frontend/src/queries/validators.js). If these get out of sync or weren't properly regenerated, it could cause validation failures.

⚠️ Error handling consistency: The parse_semver function in posthog/hogql/property.py raises generic ValueError exceptions which are then caught and converted to QueryError. This indirection could potentially mask debugging information if the error propagation isn't handled correctly.

⚠️ Performance consideration: The semver range operators generate complex AND conditions with multiple sortableSemver function calls, which could impact query performance for large datasets with many semver comparisons.

Confidence Score: 4/5

The implementation is well-structured and comprehensive with excellent test coverage. The risk level is moderate due to the complexity of the HogQL integration and potential for schema synchronization issues, but the foundational nature of the change and thorough testing provide good confidence in the implementation.