Organise the replay report around requests, not around everything at once
- Dominant language
- Rust
- Stars
- 2
- Forks
- 1
- Avg merge
- 21h 32m
- Merged PRs (30d)
- 67
Description
The replay report page shows everything at once. A reader arriving at a failed
run gets a header, a trust strip, eight counter tiles, a per-boundary table, a
per-correlation table, a finding list and the unified call view, all expanded,
before they know which request they care about. The information is all correct
and it is all there; the problem is that none of it is scoped to a question a
reader actually has.
The question a reader has is almost always "which requests diverged, and what
happened in that one". So the page should be organised around requests.
## The shape
A summary at the top: the verdict, how many requests were driven, how many
matched, and the counts that decide whether the run is worth reading at all.
Below it, one row per request — collapsed. A row says which request it is,
whether it passed, and how much diverged in it. Clicking a row expands it in
place; clicking again collapses it. Everything about that request lives inside
its own row: its status and body comparison, its side-effect calls, its
diffs, its span alignment. Nothing about any other request is on screen.
The current page is not missing information. It is missing the fold.
## What already exists
This is a reorganisation of the dashboard, not a change to the scorer or the
API. `CorrelationOutcome` (`crates/deja-orchestrator/src/divergence/mod.rs`)
already carries, per request: `correlation_id`, `http_status_match`,
`http_body_match`, `side_effect_divergences`, `scoring_mode`, `alignment`,
`span_shape`, `inconclusive` and `passed`. That is the collapsed row, complete,
with no new field required.
The expanded body is a filter rather than a fetch: rows from
`GET /runs/{id}/calls` and `GET /runs/{id}/http-diffs` already carry
`correlation_id`, so the existing evidence components can be reused unchanged
against a single correlation's subset.
`CorrelationTable` (`web/src/pages/ReportPage.tsx:377`) already renders the row
list. What is missing is the expansion, the filtering, and removing everything
that currently sits outside it.
## Two things to fix in the same work, because the redesign touches them
An **inconclusive** correlation currently renders as `diverged`
(`web/src/pages/ReportPage.tsx:396` — `row.passed ? "reproduced" : "diverged"`).
`CorrelationOutcome.inconclusive` exists precisely so that an unjudgeable
correlation is held apart from a failing one, and the request row is where that
distinction becomes visible instead of theoretical. A request-first page that
still calls an unjudgeable request a failing one has the same defect in a new
layout.
`http_status_match`, `http_body_match` and `passed` are typed
`boolean | undefined` in the client (`web/src/lib/api.ts:195-198`) and tested
truthily at `ReportPage.tsx:392-395`, so an absent value reads as a definite
negative finding. In a summary-first page that mistake is louder, because the
row is the whole reader sees before deciding whether to expand.
## Not in scope here
The call-kind rendering gap is a separate and more urgent bug and should not
wait for this: the evidence dispatch branches on four kinds and falls through
to the matched panel for the rest, so several kinds — including blocking ones —
are shown as agreeing. That needs fixing on the current page, and this redesign
should be built on top of the fix rather than around it.
## Worth settling before building
How the row is labelled. A correlation id is not a thing a reader recognises;
whatever identifies the request to a human — the endpoint, the flow, the
merchant — is what the row should lead with, and that may need a field the
scorecard does not carry yet.
Whether more than one row can be open at once. Reading two diverging requests
side by side is a real need when the divergence is a pattern rather than a
one-off, and it is much harder to add later than to allow from the start.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with CorrelationTable in web/src/pages/ReportPage.tsx and the CorrelationOutcome definition in crates/deja-orchestrator/src/divergence/mod.rs, then trace the existing evidence components and calls/diffs data. Resolve how rows identify requests and whether multiple rows may stay open. Done means the report has a summary and collapsed request rows with scoped evidence, while inconclusive and undefined boolean values are represented distinctly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust, typescript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100