fix: 🐛 versions are parsed as integers instead of numbers

[SirTenzin]

---

Summary by cubic

Switch version handling to decimal numbers across API and UI, and add explicit variant schema for products. This unblocks plan variants on feat/plan-variants and removes the old auto-detection flow.

• New Features

  • Introduced variant schema: products now have internal_parent_product_id and variant_id; prices/entitlements include variant_action and base_* IDs; product uniqueness keyed by parent/variant; responses map base_variant_id from internal_parent_product_id.
  • Updated services: ProductService and pricecn hide items with variant_action="removed" and resolve parent links; removed DetectBaseVariant job, enum, and queue wiring.

• Bug Fixes

  • Version parsing now uses numbers, not integers: added queryNumber, switched product internal/count routes to it, replaced parseInt with parseFloat in handlers and EditPlanHeader, and updated validation/customer search to support decimals.

^{Written for commit 159fa97. Summary will update on new commits.}

Greptile Summary

This PR fixes a bug where product version numbers were being parsed as integers (via parseInt) instead of floating-point numbers, which prevented decimal versions (e.g. 1.1, 1.5) from being handled correctly across the API and frontend.

Key changes:

• Bug fixes — parseInt replaced with Number.parseFloat in CusSearchService.ts and handleGetCustomerProduct.ts to correctly preserve decimal version values when filtering and fetching customer products.
• Bug fixes — parseInt(version, 10) replaced with parseFloat(version) in EditPlanHeader.tsx so the frontend version-change handler also handles decimal versions properly.
• Improvements — A new queryNumber Zod helper is added in queryHelpers.ts, mirroring the existing queryInteger but without the .int() constraint, enabling decimal query params for version fields.
• API changes — handleGetProductCount.ts and handleGetProductInternal.ts switch their version query schema from queryInteger to queryNumber, aligning validation with the now-supported decimal version format.

Confidence Score: 5/5

• This PR is safe to merge — the changes are narrowly scoped, well-reasoned, and fully backward-compatible.
• All changes are correct and targeted. Replacing parseInt with parseFloat preserves integer-version queries while enabling decimal versions. The new queryNumber helper is a clean addition following established patterns. All modifications are backward-compatible.
• No files require special attention.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["Query param: version string\n(e.g. '1', '1.5')"] --> B{Handler / Schema}

    B -->|"handleGetProductInternal\nhandleGetProductCount"| C["queryNumber()\nzod preprocess"]
    B -->|"handleGetCustomerProduct"| D["Number.parseFloat(version)"]
    B -->|"CusSearchService"| E["Number.parseFloat(version)"]
    B -->|"EditPlanHeader (frontend)"| F["parseFloat(version)"]

    C --> G["z.number() — allows decimals"]
    D --> H["Passed to ProductService.getFull()\nor productToCusProduct()"]
    E --> I["productVersionFilters object"]
    F --> J["setQueryStates({ version })"]

    G --> H

Loading

_{Last reviewed commit: b040107}

Context used:

• Context from dashboard - When generating the key changes section of the summary, please tag each change with one or many of t... (source)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
autumn-vite	Ready	Preview, Comment	Mar 5, 2026 3:57pm

[cubic-dev-ai]

1 issue found across 6 files

Confidence score: 3/5

• There is a concrete validation risk in shared/api/common/queryHelpers.ts: queryNumber uses parseFloat, so malformed inputs like "1abc" can be accepted as valid numbers.
• Because this is severity 7/10 with high confidence (9/10) and affects request parameter validation, it carries real user-impact/regression risk if merged as-is.
• This is likely fixable with stricter numeric parsing/checks, but until then the merge has moderate risk rather than being fully safe.
• Pay close attention to shared/api/common/queryHelpers.ts - numeric query validation may incorrectly allow malformed values.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="shared/api/common/queryHelpers.ts">

<violation number="1" location="shared/api/common/queryHelpers.ts:125">
P1: `queryNumber` uses `parseFloat`, which accepts malformed numeric strings with trailing characters (e.g., `"1abc"`). This can let invalid query params pass validation as valid numbers.</violation>
</file>

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

[cubic-dev-ai]

P1: queryNumber uses parseFloat, which accepts malformed numeric strings with trailing characters (e.g., "1abc"). This can let invalid query params pass validation as valid numbers.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At shared/api/common/queryHelpers.ts, line 125:

<comment>`queryNumber` uses `parseFloat`, which accepts malformed numeric strings with trailing characters (e.g., `"1abc"`). This can let invalid query params pass validation as valid numbers.</comment>

<file context>
@@ -96,3 +96,35 @@ export function queryInteger(options?: {
+			return val;
+		}
+		if (typeof val === "string") {
+			const parsed = Number.parseFloat(val);
+			return Number.isNaN(parsed) ? val : parsed;
+		}
</file context>