juspay / juspay/deja

Organise the replay report around requests, not around everything at once

Open
#114 0 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.