fix(flags): reject leading-zero versions in sortableSemVer

[dmarticus]

Problem

The HogQL sortableSemVer function (used to compute the rollout
blast-radius preview for feature flags with semver comparisons)
extracted the first dot-separated digit run from the property value
without enforcing strict semver rules. As a result \"3.07\" was
parsed as [3, 7] — exactly the same as \"3.7\" — so the preview
counted users with version \"3.07\" as matching a version >= 3.7
filter.

Runtime flag evaluation (Rust, semver crate)
rejects \"3.07\" outright. So a flag that the preview said would hit
N users actually hit fewer at runtime, and customers were filing the
discrepancy as a bug.

Changes

• HogQL sortablesemver (posthog/hogql/functions/posthog.py):
  swap the lenient (\\d+(\\.\\d+)+) extraction for a strict, anchored
  regex that only matches MAJOR.MINOR.PATCH with no leading zeros,
  optionally with a v prefix or pre-release / build-metadata suffix.
  Invalid input now becomes NULL (via nullIf(extract(...), '')),
  which propagates through splitByChar/arrayMap and makes every
  semver comparison NULL — equivalent to false in WHERE, so the
  row is excluded. This matches what the Rust path does when
  Version::parse returns None.
• Rust regression test (rust/feature-flags/src/properties/property_matching.rs):
  extend test_semver_invalid_versions with explicit assertions for
  \"3.07\", \"3.7\", and \"3.0\" to pin the strict-rejection
  behavior of the source-of-truth path so it can't silently relax.
• HogQL tests (posthog/hogql/test/test_query.py):
  tighten test_sortable_semver to only sort strict X.Y.Z inputs,
  rewrite test_sortable_semver_output to cover the new accept-list
  (plain, v prefix, pre-release suffix, all-zero), and add two new
  tests — test_sortable_semver_rejects_invalid (lists everything
  Rust rejects and asserts IS NULL) and
  test_sortable_semver_invalid_excluded_from_comparisons (the exact
  bug repro: sortableSemVer('3.07') >= sortableSemVer('3.7.0') is
  now NULL instead of true).
• Printer test (posthog/hogql/printer/test/test_printer.py):
  update the expected ClickHouse SQL string for the new template.

Behavior change to be aware of

Any value that isn't strict X.Y.Z (with no leading zeros) is now
treated as unmatchable for semver operators in the blast-radius
preview. That includes two-component versions like \"3.7\",
four-plus-component versions like \"1.2.3.4\", and trailing garbage
like \"2.2.0.betabac\". This is the intentional alignment with Rust
— blast radius now reflects what flag evaluation will actually do —
but it does change the number reported in the UI for projects whose
app-version property doesn't use strict semver. Worth a heads-up in
release notes.

How did you test this code?

I'm an agent (Claude Code).

• ✅ Ran the Rust test locally:
  cargo test --package feature-flags --lib test_semver_invalid_versions
  passes with the new assertions for \"3.07\", \"3.7\", \"3.0\".
• ✅ Cross-checked the new HogQL regex against ~25 input strings using
  a Python harness (mirroring the extract + capture-group-1 +
  nullIf flow), covering: strict valid (1.2.3, 0.0.0,
  v1.2.3-alpha+build, whitespace padding), the user-reported bug
  (3.07), other leading-zero shapes (01.2.3, 1.02.3, 1.2.03,
  01.02.03), wrong arity (3.0, 3.7, 1.2.3.4, 0.9,
  1.9.233434.10, 0.0.0.0.1000), structural junk (1..2.3,
  .1.2.3, 1.2.3., 1.-2.3, 2.2.0.betabac), and totally
  unparseable input (abc, \"\"). All 25+ matched expectations.
• ❌ Did not run the HogQL integration tests locally — couldn't
  bring up local ClickHouse, leaving verification to CI.

Open item for reviewers

The fix relies on ClickHouse propagating NULL through
splitByChar('.', NULL) and arrayMap(f, NULL). The docs say
non-NULL-aware functions return NULL on NULL input, but I couldn't
confirm specifically for the higher-order arrayMap path. If CI
reveals it does not propagate, the fallback is to special-case
sortablesemver in posthog/hogql/printer/clickhouse.py (next to
lookupOrganicSourceType) and emit an explicit
if(empty(extract(...)), NULL, arrayMap(...)) that references args[0]
twice. Happy to land that follow-up if the integration tests flag it.

Publish to changelog?

no

🤖 Agent context

Authored by Claude Code (Opus 4.7, 1M context) — Dylan kicked it off
with a description of the user-visible blast-radius bug and an
explicit ask to match the Rust path strictly (chosen via
`AskUserQuestion` over only-fix-leading-zeros and
make-Rust-more-lenient). I rejected an earlier draft that just tweaked
the regex inside `extract` (it would silently truncate `"3.07"` to
`"3.0"`) and went with anchored-regex + capture-group-1 + `nullIf`
instead because it falls back to `NULL` rather than to a bogus
parsed array. The Rust test was added first so the source-of-truth
behavior is pinned regardless of how the HogQL fallback shakes out.

[github-actions]

🎭 Playwright didn't run on this PR — your changes touch code that could affect E2E behavior, but Playwright is opt-in via label now to keep CI cost down.

Add the run-playwright label if you want an E2E sweep before merging — CI will pick it up automatically.

Most PRs don't need this. Real regressions still get caught on master and fix-forward.

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
posthog/hogql/test/test_query.py:1905-1957
**Prefer parameterised tests**

`test_sortable_semver_rejects_invalid` and `test_sortable_semver_invalid_excluded_from_comparisons` test multiple distinct inputs by concatenating them into one SQL string. Per the team's convention ("We always prefer parameterised tests"), each invalid-version case should ideally be its own parameterised invocation so that failures pinpoint the exact offending input rather than the whole query. The batch-query design here is efficient for ClickHouse round-trips, but a `@parameterized.expand` (or `@pytest.mark.parametrize`) approach on individual `SELECT sortableSemVer('{version}') IS NULL` calls would make failures immediately actionable without having to inspect the result-set difference.

_{Reviews (1): Last reviewed commit: "fix(flags): reject leading-zero versions..." | Re-trigger Greptile}

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-05-21 15:53 UTC	Run
prod-us	✅ Deployed	2026-05-21 16:10 UTC	Run
prod-eu	✅ Deployed	2026-05-21 16:10 UTC	Run