feat: narrow the original search with a trace-id subquery when searching from a correlated event - #3018
feat: narrow the original search with a trace-id subquery when searching from a correlated event#3018karl-power wants to merge 2 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: f7777ca The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
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 |
🟡 Tier 3 — StandardIntroduces new logic, modifies core functionality, or touches areas with non-trivial risk. Why this tier:
Review process: Full human review — logic, architecture, edge cases. Stats
|
Greptile SummaryThis PR preserves the original search source when searching from a correlated event by generating an editable trace-ID SQL subquery.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| packages/app/src/utils/correlatedSearch.ts | Builds the trace-ID subquery and now safely quotes configured database and table identifiers. |
| packages/app/src/DBSearchPage.tsx | Distinguishes explicit source pivots from correlated-event narrowing while preserving the searched source configuration. |
| packages/app/src/components/DBRowOverviewPanel.tsx | Generates escaped SQL attribute paths for cross-source resource-attribute search actions. |
| packages/app/src/components/DBHighlightedAttributesList.tsx | Selects SQL predicates for correlated attributes while retaining Lucene predicates for same-source and explicit-pivot actions. |
| packages/app/tests/e2e/features/search/cross-source-search.spec.ts | Covers URL generation, source preservation, SQL execution, and overview attribute searches across correlated sources. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart LR
A[Original search source] --> B[Open correlated event]
B --> C[Search for this value only]
C --> D[Build event-source SQL predicate]
D --> E[Build TraceId IN subquery]
E --> F[Search original source]
Reviews (2): Last reviewed commit: "fix quoting and escaping" | Re-trigger Greptile
Deep Review✅ No critical issues found. This is a self-contained, well-tested frontend change. The two prior P1 review comments (unquoted table identifiers in 🟡 P2 — recommended
🔵 P3 nitpicks (2)
Pre-existing (not introduced by this diff): The Column Values "Search for this value only" action in Design note (accepted trade-off): The subquery targets the event source's table (e.g. Reviewers (10): correctness, security, adversarial, testing, maintainability, kieran-typescript, project-standards, previous-comments, agent-native, learnings-researcher. Coverage note: Findings were synthesized from a direct trace of the full data flow (EventTag → Testing gaps: No direct unit test of |
E2E Test Results✅ All tests passed • 327 passed • 1 skipped • 1289s
Tests ran across 4 shards in parallel. |
…ing from a correlated event
b6a28cd to
f7777ca
Compare
| ? `${quoteIdentifierIfNeeded(databaseName)}.${quotedTable}` | ||
| : quotedTable; | ||
|
|
||
| return `${searchedTraceId} IN (SELECT ${eventTraceId} FROM ${eventTable} WHERE ${eventWhere.trim()})`; |
There was a problem hiding this comment.
I suspect this will not scale past relatively small data volumes. Here are the issues I see:
- If I'm reading this right, the subselect is not bound by a time range, so it's a full table scan in most cases
- I suspect the custom SQL
eventWherewill not hit many of our optimizations that try to make use of indexes, like rewrites for using full-text indexes when accessing attributes, it would be good to check that and see if we can do anything to ensure they work - Making (1) worse is the fact that the search page is paginated, so for every page of results, the full-table scan re-runs despite querying the same results. Are there ways we can cache the subselect results?
- For conditions that return a lot of traces (eg. 10B traces match the filter), the sub-select returns a very large result set, which is then like a very high-cardinality join, which can use a lot of memory or spill to disk. Should we consider putting a limit on the subselect? This could be a worse user experience though because the results will generally not be complete. This is a difficult problem to solve when the filtering by a low-specificity condition, we've struggled with it in the past.
Summary
"Search for this value only" on an event from a correlated source (e.g. a log opened from a trace search) previously switched the search to the event's source (#2825), losing the original search's context. It now keeps the searched source, select, and filters, and replaces the search box with a trace-id subquery on the event's table in plain SQL the user can see and edit:
pivotflag ongenerateSearchUrl.Screenshots or video
Screen.Recording.2026-08-28.at.15.32.38.mov
How to test on Vercel preview
Preview routes:
/searchSteps:
TraceId IN (SELECT ...)SQL condition in the search box, and results load without a SQL error.References