fix: nested-JSON "Add to Filters" crashes search page with Lucene SyntaxError#2398
Draft
MikeShi42 wants to merge 2 commits into
Draft
fix: nested-JSON "Add to Filters" crashes search page with Lucene SyntaxError#2398MikeShi42 wants to merge 2 commits into
MikeShi42 wants to merge 2 commits into
Conversation
"Add to Filters" on a nested-JSON attribute builds a ClickHouse SQL expression (e.g. JSONExtractString(LogAttributes['weird.key.payload'], 'abc.def.jqk/abcd')) as the filter field. filtersToQuery previously emitted this as the field side of a Lucene term, producing a query that lucene.parse cannot parse (opens a range at the '[' and throws SyntaxError), crashing the search page at chart render time. Detect raw SQL-expression keys (containing parens/brackets/quotes/ whitespace that cannot appear in a Lucene field name) and emit a SQL IN/NOT IN/BETWEEN filter instead, which flows straight into the WHERE clause and round-trips through parseQuery/extractInClauses. Plain field paths keep using Lucene. Co-authored-by: Mike Shi <mike@hyperdx.io>
…arseQuery Verify nested-JSON "Add to Filters" SQL filters (JSONExtractString IN (...)) survive the filtersToQuery -> parseQuery URL round-trip, including single-quote SQL escaping and combined included/excluded values. Co-authored-by: Mike Shi <mike@hyperdx.io>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Contributor
E2E Test Results✅ All tests passed • 139 passed • 3 skipped • 929s
Tests ran across 3 shards in parallel. |
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
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.
Resolves HDX-4427
Summary
"Add to Filters" on an attribute reached through a parsed JSON string column builds a ClickHouse SQL expression as the filter field — e.g.
JSONExtractString(LogAttributes['weird.key.payload'], 'abc.def.jqk/abcd').filtersToQuerythen emitted this expression as the field side of a Lucene term (<expr>:"asdf-14"). The Lucene PEG parser hits the[afterLogAttributes, opens a range expression, and throws when it sees]where it expects a range body:Because
SearchQueryBuilder.build()parses the filter condition at render time for every tile/chart, the whole search page crashes.Why this fix (option c from the issue): A field that is a raw SQL function call cannot be represented as a Lucene field name, and escaping a full SQL expression (parens, brackets, quotes, commas, slashes, spaces) to survive both
lucene.parseand theencodeSpecialTokens/decodeSpecialTokensround-trip is fragile. The semantically correct representation is a SQL filter, which flows straight into the WHERE clause and never touches the Lucene parser (renderWhereExpressionStronly invokesSearchQueryBuilder/parse()whenlanguage === 'lucene').filtersToQuerynow detects raw SQL-expression keys — those containing parentheses/brackets/quotes/whitespace that cannot appear in a Lucene field name — and emitsIN/NOT IN/BETWEENSQL filters for them. Plain field paths (including bracket-form Map keys, which normalize to dot form) keep using Lucene exactly as before. The emitted SQL shape matches what the app'sparseQuery/extractInClausesreads back, so these filters round-trip through the URL.Changes
packages/common-utils/src/filters.ts: detect SQL-expression field keys infiltersToQueryand emitsqlfilters (IN/NOT IN/BETWEEN) with SQL string escaping that inverts the app'sgetBooleanOrUnquotedString.packages/common-utils/src/__tests__/filters.test.ts: emission + escaping + "still Lucene for plain fields" cases.packages/common-utils/src/__tests__/nestedJsonAddToFilters.test.ts: regression — the old Lucene string throws viaparse(); the new handler emits a SQL filter; any Lucene the handler still emits parses successfully.packages/app/src/__tests__/searchFilters.test.ts: fullfiltersToQuery→parseQueryround-trip for SQL-expression filters (included/excluded, single-quote escaping).Screenshots or video
N/A — query-generation logic fix, no UI rendering change. The crash lived entirely in the filter-to-query logic, so it is best demonstrated by rendered SQL / parser output. End-to-end evidence (run against the built
distthe app imports):e2e_nested_json_filter_fix.log
How to test on Vercel preview
N/A — non-UI change.
References
To show artifacts inline, enable in settings.