Repository navigation
Open the trace panel's signal disclosure on a signal or value winner - #516
Merged
Merged
Conversation
This was referenced Sep 23, 2026
Owner
Author
This was referenced Sep 23, 2026
thebhef
force-pushed
the
task153-host-gate
branch
from
September 23, 2026 16:46
cd2ea28 to
b4bcd78
Compare
thebhef
force-pushed
the
task153-panel
branch
from
September 23, 2026 16:46
b58a59c to
aee6548
Compare
thebhef
force-pushed
the
task153-host-gate
branch
from
September 24, 2026 01:39
b4bcd78 to
7a83295
Compare
thebhef
force-pushed
the
task153-panel
branch
from
September 24, 2026 01:39
aee6548 to
00207e4
Compare
This was referenced Sep 24, 2026
This was referenced Oct 6, 2026
Open
thebhef
marked this pull request as ready for review
October 14, 2026 21:08
Owner
Author
Task 153 phase 1 (host, `task153-host-gate`) started returning a `fuzzy_winner` on the filtered-trace and by-id page envelopes and a `matching_signals` list per admitted `TraceFrameRecord`, but nothing on the frontend read either yet. This wires them into the trace panel: - `useFilteredTrace` / `useByIdView` expose the page's `fuzzy_winner` (read off the response inside `fetchPage`, via a ref so it's current by the time the state update it rides in re-renders the caller — the same trick `useFilteredTrace` already used for its incremental match count). - `TraceView` and `ByIdTable` take a `fuzzyWinner` prop. Under a `signal` or `value` winner, every admitted row's disclosure is forced open onto just its `matching_signals`; under a `message` winner or no query it is exactly the user's own fold state. The two are kept separate on purpose — the query never writes into the user's `expanded` map/set, it only overlays a different answer on top of it while the winner says to, so a message winner or a cleared query snaps straight back to whatever the user had, unmodified. The shared disclosure arithmetic (`disclosedSignals`, `queryOpensDisclosure`) lives in `traceTable.tsx`, which both views already draw rows through. - README's trace section now names the transmitting-ECU field the filter also matches (it always did; the prose just didn't say so) and spells out the signal/value-winner behaviour: hides a message admitted only by its own weaker haystack match, opens the survivors to the matching signal(s), and how a value match reads in chronological vs. by-ID mode. DOM tests (`TracePanel.dom.test.tsx`, through the same host-mock harness the file's other fuzzy-filter tests use) cover a value winner opening a row narrowed to its match, a message winner leaving a user's manual expand/collapse alone, the query-driven state reverting cleanly once the query clears or degrades to a message winner, and the by-id path showing the same behaviour. Fix: under full-suite load (two `pnpm test` runs concurrently), "leaves a message winner's rows..." failed once on its clear-the-box `waitFor`, still seeing the previous value-winner's narrowed row. The condition was right, not the ceiling: a filter-box change walks the 150 ms `useGridviewFilter` debounce (`gridviewFilter.tsx`) into a descriptor change that fires `fetch_filtered_trace` (`useFilteredTrace` -> `useWindowedQuery`, an immediate, un-throttled fetch on descriptor change) before the row re-renders — two real async hops that CPU contention can push past the default 1000 ms `waitFor` ceiling. Raised that `waitFor` and the test's earlier value-winner `waitFor` (same path) to a 5000 ms ceiling with a hop comment each, and gave the two sibling tests in the same describe block that wait on the identical debounce-then-fetch path (the value-winner-only test and the by-id test) the same treatment, so the suite doesn't fail on a sibling next time. No component change; the test still asserts the same end state. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
thebhef
force-pushed
the
task153-panel
branch
from
October 14, 2026 21:38
342fe67 to
c361c9f
Compare
This was referenced Oct 15, 2026
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.

Task 153 phase 1 (host,
task153-host-gate) started returning afuzzy_winneron the filtered-trace and by-id page envelopes and amatching_signalslist per admittedTraceFrameRecord, but nothing onthe frontend read either yet. This wires them into the trace panel:
useFilteredTrace/useByIdViewexpose the page'sfuzzy_winner(read off the response inside
fetchPage, via a ref so it's currentby the time the state update it rides in re-renders the caller — the
same trick
useFilteredTracealready used for its incremental matchcount).
TraceViewandByIdTabletake afuzzyWinnerprop. Under asignalorvaluewinner, every admitted row's disclosure is forcedopen onto just its
matching_signals; under amessagewinner or noquery it is exactly the user's own fold state. The two are kept
separate on purpose — the query never writes into the user's
expandedmap/set, it only overlays a different answer on top of itwhile the winner says to, so a message winner or a cleared query
snaps straight back to whatever the user had, unmodified. The shared
disclosure arithmetic (
disclosedSignals,queryOpensDisclosure)lives in
traceTable.tsx, which both views already draw rows through.filter also matches (it always did; the prose just didn't say so) and
spells out the signal/value-winner behaviour: hides a message
admitted only by its own weaker haystack match, opens the survivors
to the matching signal(s), and how a value match reads in
chronological vs. by-ID mode.
DOM tests (
TracePanel.dom.test.tsx, through the same host-mockharness the file's other fuzzy-filter tests use) cover a value winner
opening a row narrowed to its match, a message winner leaving a user's
manual expand/collapse alone, the query-driven state reverting cleanly
once the query clears or degrades to a message winner, and the by-id
path showing the same behaviour.
Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com