fix: searching json number property error

[karl-power]

Fixes #1238
Fixes HDX-2551

Checks if a property is a number or boolean and chooses the appropriate JSON extract function.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
hyperdx-v2-oss-app	Ready	Preview, Comment	Feb 20, 2026 4:29pm

[changeset-bot]

🦋 Changeset detected

Latest commit: e0a8d59

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@hyperdx/app	Patch
@hyperdx/api	Patch
@hyperdx/otel-collector	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

PR Review: fix: searching json number property error

✅ No critical issues found.

Minor observations:

• ⚠️ Integer values → JSONExtractFloat is used for all numbers, but integers could use JSONExtractInt for more precise matching. Edge case: a field with value 42 would be searched as a float (42.0), which may cause mismatches depending on how ClickHouse handles type coercion in the query.
• ⚠️ Copy/search actions (lines 258 and 349) don't pass jsonFunction → only the "filter" action gets the number-aware function; copy and other actions fall back to JSONExtractString. This is probably fine for copy behavior, but worth confirming search consistency across all action types.

Otherwise clean fix — good refactor of the function name and appropriate use of the default parameter.

[github-actions]

PR Review: fix: searching json number property error

• ⚠️ Chart action still uses JSONExtractString for number values (line 360-364) → The chart action is gated by typeof value === 'number' but doesn't pass JSONExtractFloat to buildJSONExtractQuery. Same root bug as the search case — charting a numeric JSON property will be broken. Should apply the same fix there.

• ℹ️ JSONExtractFloat used for all numbers including integers → For integer JSON values, JSONExtractInt would be more precise; JSONExtractFloat works for typical cases but may lose precision on large integers (>2^53).

Otherwise the fix is clean — the filter action correctly remains string-only so the JSONExtractString default there is fine.

[fleon]

Would be nice to add some tests for this function.

[github-actions]

Claude Code Review

• ⚠️ JSONExtractFloat used for all numeric types → Consider JSONExtractInt for integer values to avoid precision loss on large integers (e.g. IDs, timestamps). JSONExtractFloat (Float64) cannot represent all 64-bit integers exactly.
• ⚠️ Path segments are interpolated without escaping single quotes → Keys containing apostrophes would produce malformed SQL. Escape with p.replace(/'/g, "''"). (Pre-existing issue, but worth fixing here since this code is being touched.)

✅ Logic is correct, type detection approach is sound, and test coverage is thorough.

[github-actions]

Claude Code Review

• ⚠️ JSONExtractFloat used for all numeric types → Consider JSONExtractInt for integer values to avoid precision loss on large integers (e.g. IDs, timestamps). JSONExtractFloat (Float64) cannot represent all 64-bit integers exactly.
• ⚠️ Path segments are interpolated without escaping single quotes → Keys containing apostrophes would produce malformed SQL. Escape with p.replace(/'/g, "''"). (Pre-existing issue, but worth fixing here since this code is being touched.)
• ⚠️ Chart action (line ~358) still uses default JSONExtractString for numeric values → If charting numeric JSON fields is supported, apply the same type-detection logic there.

✅ Logic is correct, type detection approach is sound, and test coverage is thorough.

[github-actions]

Claude Code Review

• ⚠️ JSONExtractFloat used for all numeric types → Consider JSONExtractInt for integer values to avoid precision loss on large integers (e.g. IDs, timestamps). JSONExtractFloat (Float64) cannot represent all 64-bit integers exactly.
• ⚠️ Path segments are interpolated without escaping single quotes → Keys containing apostrophes would produce malformed SQL. Escape with p.replace(/'/g, "''"). (Pre-existing issue, but worth fixing here since this code is being touched.)

✅ Logic is correct, type detection approach is sound, and test coverage is thorough.

[github-actions]

E2E Test Results

✅ All tests passed • 70 passed • 4 skipped • 837s

Status	Count
✅ Passed	70
❌ Failed	0
⚠️ Flaky	1
⏭️ Skipped	4

Tests ran across 4 shards in parallel.

View full report →