Skip to main content

Module runs

Module runs 

Source
Expand description

Historical-runs capability: inspect the run history of a (corpus, service) as an agent API (the JSON twin of the human history screen).

Follows the symmetry contract — one shared RunDto is the read model for both the agent API (GET /api/runs/...) and the server-rendered human screen (runs_page, GET /runs/...). Handlers live here; the app is assembled in crate::frontend::server. The binary’s legacy history page (Vega charts) still renders today and migrates onto this surface in a later increment.

Structs§

RunDiffDto
A comparison of two saved task-status snapshots of a (corpus, service): the status-transition matrix (what improved / regressed between runs) plus the snapshot dates available to compare.
RunDiffTransitionDto
One cell of the run-comparison matrix: how many tasks moved from previous_status to current_status between the two snapshots.
RunDto
A historical (corpus, service) run as exposed over the API: a stable id handle, who/why/when, whether it has completed, and the per-severity task tallies. For a completed run these are the snapshot frozen at completion; for an open run they are overlaid with live progress (HistoricalRun::with_live_tallies), since stored tallies are only frozen at completion — so an in-progress run reports its real state, not zeros.
RunOverviewDto
A historical run as exposed in the system-wide overview: the per-(corpus, service) RunDto fields plus the corpus + service names (the overview spans every pair, so the names are part of the row). The read model for GET /api/runs and the /admin/runs management screen.
TaskDiffDto
A single task’s status transition between two snapshots — which document regressed or improved, and when each snapshot was taken.

Functions§

all_runs_page
The system-wide run-management overview (GET /admin/runs): the most recent runs, filterable by corpus/service/owner, each linking into its per-service history + diff drill-downs. Signed-in admins only (unauthenticated → sign-in, returning here).
api_all_runs
The system-wide run history (agent twin of the /admin/runs screen): the most recent runs, newest first, optionally filtered by corpus/service/owner, capped at limit (default 100, max 500). 503 if the pool is exhausted.
api_run_current
Returns the currently open run of a (corpus, service), or null if none is in progress. 404 if the corpus or service is unknown.
api_run_diff
Compares two task-status snapshots of a (corpus, service) (the agent twin of the diff-summary screen). previous/current are snapshot timestamps from available_dates; omit them to use the most recent saved pair. 400 on a malformed date, 404 if the corpus/service is unknown.
api_run_task_diffs
Lists the individual tasks whose status changed between two snapshots of a (corpus, service) — the drill-down behind the comparison matrix (which documents regressed/improved). Optionally filtered to a previous_status/current_status transition and paginated (offset/page_size, default 100). 400 on a malformed date or status, 404 if the corpus/service is unknown.
api_runs
Lists the run history of a (corpus, service), most-recent first (the agent twin of the history screen). 404 if the corpus or service is unknown.
history_page
The former standalone history chart page. The success-rate Vega chart is now merged into runs_page, rendering inline above the run-history table at /runs/<corpus>/<service>, so this route redirects there — keeping old links, bookmarks, and nav entries working.
routes
The route set for the historical-runs capability.
runs_diff_page
The human diff-summary screen: the server-rendered status-transition matrix between two snapshots — the 1:1 HTML twin of api_run_diff, sharing RunDiffTransitionDto. A snapshot pair is chosen with two date dropdowns (a JS-free <form method=get>); each transition cell links into the runs_tasks_page drill-down pre-filtered to that previous → current transition. Reuses parse_snapshot_date, so a malformed date is a 400 and 404 on an unknown corpus/service. It replaced the legacy diff-summary binary route, which .unwrap()ed the date and panicked on the dispatch path (the F-1 gap, now closed).
runs_page
The human run-history screen: a server-rendered table of the same runs GET /api/runs/... returns (the 1:1 HTML twin, sharing RunDto). 404 if the corpus/service is unknown.
runs_tasks_page
The human task-diff screen: a server-rendered, filterable table of the individual tasks whose status changed between two snapshots — the 1:1 HTML twin of api_run_task_diffs, sharing TaskDiffDto. This is the filter-driven heart of run management: pick a previous_status → current_status transition (and optionally a snapshot pair) and see exactly which documents regressed or improved. This parses gracefully: 400 on a malformed date/status, 404 on an unknown corpus/service, and an empty filter just lists every change. It replaced the legacy diff-history binary route, which .expect()ed the status params and .unwrap()ed the dates — panicking on the dispatch path (the F-1 gap, now closed).