web: show context lines for text-filtered logs, not just level-filtered ones - #6825
Open
MIreland wants to merge 2 commits into
Open
web: show context lines for text-filtered logs, not just level-filtered ones#6825MIreland wants to merge 2 commits into
MIreland wants to merge 2 commits into
Conversation
LogDisplay.shouldDisplayPrologues() only kept the rolling context buffer (the lines shown right before a match) when a level filter was active. Text search got none of it, so filtering the log pane by a term returns just the bare matching lines with no surrounding context — useless when the match is one field of a pretty-printed JSON record, for example. Extend the gate to cover a parsed term as well, and split out matchesPrologueFilter() (level + term, no source) as the single "is this line a hit" predicate, reused by OverviewLogPane in the next commit. Also cap the per-span prologue buffer at DISPLAY_LOG_PROLOGUE_LENGTH as lines come in, rather than growing it unboundedly and slicing only at match time — harmless for level filters (matches are frequent), but a term search over a long, otherwise-unfiltered session could otherwise buffer arbitrarily many lines per span while waiting for a match.
isStartOfAlert / isEndOfAlert decided a match group's boundary by comparing line levels, which only made sense because every line matching a level filter shares that exact level. A term filter's matches don't share anything so predictable, so drive the boundary off match state (matchesPrologueFilter) instead of level equality — this works identically for both filter kinds and is arguably clearer either way. With this, a term filter's context lines now get the same divider/spacing treatment and the same "… (more) …" link back to the unfiltered view that level filters already had. Updates the term-filter tests to assert the new (intended) behavior instead of the old bare-matches-only one, and adds coverage for consecutive matches (no repeated context), a match near the start of a span (short prologue, no crash), and level+term filters combined.
MIreland
force-pushed
the
mi/log-filter-term-prologues
branch
from
August 14, 2026 14:04
ef140b9 to
3e3afdf
Compare
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
1 participant
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.
Disclaimer: Everything below the screenshot was written by claude.
We got this piece of feedback from an engineer:
Fixes #6824.
Text search in the log pane currently shows only the bare matching lines, with no context — unlike level filters (Errors/Warnings), which already show a few lines of lead-in before each match via a rolling per-span buffer ("prologues").
This PR extends that existing mechanism to text search instead of building a new one.
Changes
web/src/logs.tsshouldDisplayPrologues()now returnstruefor a parsed term filter as well as a level filter.matchesPrologueFilter()(level + term, no source) as the single "is this line a hit" predicate, shared byOverviewLogPane.trackPrologueLine()now caps the buffer atDISPLAY_LOG_PROLOGUE_LENGTHas lines come in, rather than growing it unboundedly and slicing only at match time. This didn't matter for level filters (matches are frequent), but a term search over a long, otherwise-unfiltered session could otherwise buffer arbitrarily many lines per span while waiting for a match.web/src/OverviewLogPane.tsxisStartOfAlert/isEndOfAlertused to compare line levels to find a match group's boundary — which only worked because every line matching a level filter shares that exact level. A term filter's matches don't share anything so predictable, so both now compare match state (matchesPrologueFilter) instead. This works identically for level filters too.web/src/OverviewLogPane.test.tsxTesting
yarn test --watchAll=false— full suite passes (363 tests).yarn check(prettier + tsc + eslint) — clean.