Skip to content

Open the trace panel's signal disclosure on a signal or value winner - #516

Merged
thebhef merged 1 commit into
mainfrom
task153-panel
Oct 14, 2026
Merged

thebhef merged 1 commit into
mainfrom
task153-panel

Conversation

@thebhef

@thebhef thebhef commented Sep 23, 2026

Copy link
Copy Markdown
Owner

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.

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

thebhef commented Sep 23, 2026 •

Copy link
Copy Markdown
Owner Author

This stack of pull requests is managed by Graphite. Learn more about stacking.

thebhef commented Oct 14, 2026 •

Copy link
Copy Markdown
Owner Author

Merge activity

  • Oct 14, 9:10 PM UTC: A user started a stack merge that includes this pull request via Graphite.
  • Oct 14, 9:39 PM UTC: Graphite rebased this pull request as part of a merge.
  • Oct 14, 9:42 PM UTC: @thebhef merged this pull request with Graphite.

@thebhef
thebhef changed the base branch from task153-host-gate to graphite-base/516 October 14, 2026 21:33
@thebhef
thebhef changed the base branch from graphite-base/516 to main October 14, 2026 21:37
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
thebhef merged commit c96e5ba into main Oct 14, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant