[9.4] [Discover][Traces] Fix nonHighlightingFilters lost in session tab serialization (#261558)#264345
Merged
Merged
Conversation
…ialization (elastic#261558) ## Summary Relates to elastic#261234 `nonHighlightingFilters` was silently dropped during `fromStoredTab` / `toStoredTab` serialization in the Discover session embeddable as part of [[Discover Sessions as Code] Discover search embeddable: API schema, transforms, and feature flag](elastic#255213). This caused the logs section in the traces flyout to run without the trace context filter (`trace.id`, `transaction.id`, `span.id`), returning all logs in the index instead of only the ones correlated to the opened trace document. |Before|After| |-|-| |<img width="1496" height="965" alt="Screenshot 2026-04-07 at 15 05 34" src="https://github.com/user-attachments/assets/9a1f21cd-3359-4753-b7d6-3bf1e3cef758" />|<img width="1495" height="965" alt="Screenshot 2026-04-07 at 15 03 34" src="https://github.com/user-attachments/assets/87fb9b18-6bef-49dd-94ec-a3eea1d895f8" />| `nonHighlightingFilters` was introduced in [[One Discover] [Logs UX]Add support to disable highlighting for certain filters we deem internal](elastic#239402) to allow certain filters (trace context constraints) to be applied to the ES query without affecting result highlighting. The `fromStoredTab` / `toStoredTab` serialization round-trip was added later in [[Discover Sessions as Code] Discover search embeddable: API schema, transforms, and feature flag](elastic#255213) and never included this field. ~~The fix ensures `nonHighlightingFilters` is read back from the serialized search source in `fromStoredTab` and written into `toStoredTab`, and adds the corresponding field to the server-side schema.~~ The fix avoids exposing `nonHighlightingFilters` as a public API schema field entirely. Since trace context filters are always runtime-derived from the opened document (`traceId`, `spanId`, `transactionId`), they never need to be persisted in the serialized state. The runtime prop path, `nonHighlightingQuery` → `createLogEventsRenderer` → `nonHighlightingFilters` on the initial searchSource, already handles the use case correctly on every mount. A `syncNonHighlightingFilters` effect has also been added to `SavedSearchComponentTable` as a defensive measure, consistent with how other dynamic props (`filters`, `query`, `timeRange`) are synced after mount. A defensive e2e test has been added: it opens the minimal trace flyout (2 correlated logs) and asserts the logs section shows exactly 2 results. (cherry picked from commit ca6f9ec)
Contributor
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Async chunks
History
cc @iblancof |
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.
Backport
This will backport the following commits from
mainto9.4:Questions ?
Please refer to the Backport tool documentation