Task: Read a run's errors and its job chain from the shell
Table of Contents
Register every generated reporting shell unit, not only the two that were missing, and guard the component with the composition check that until now only covered refdata. Serve every error read through the generated registrars instead of the two hand-rolled subscriptions.
This page documents a task in the Prove the report grid run end to end — the remaining work story. It captures the goal, current status, acceptance, and any notes or results.
1. Goal
The run's reasons and its job chain are readable from ores.shell: a person can ask for the errors of a run and walk from the run to its batch, its workunit and its result without going through the web.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent story | Prove the report grid run end to end — the remaining work |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-25 |
3. Acceptance
- `report_error_events by-report-instance-id <id>` answers with the run's rows.
- `report_error_scopes list` answers with the scope catalogue.
- Every generated reporting shell unit is registered and reachable.
- The composition check covers ores.reporting, so an unregistered unit fails the gate.
4. Plan
(Implementation strategy. Written when work starts; key decisions
are distilled into the parent story's * Decisions at close, but the
plan itself stays — it is the historical record of what we did.)
5. Measurements
Every number this task claims about a tree, with the command that produced it
and the commit it was measured at. A number without both is not a measurement,
because a clean-up record describes a tree and trunk moves under a branch: a
consumer count, a gate's component count and a suite's size all change with no
code changing, and the reader of a bare number cannot tell which tree it came
from. Where the raw output matters, put it in an evidence/ file beside the
task and name that file in the Command column.
| What | Value | Command | Commit |
|---|---|---|---|
6. Notes
7. Test Scenarios
Manual QA scenarios (scaffolded via compass add test_scenario)
that verify this task. Link
new ones here as they're created; the scenario doc itself links back
via its "Verifies task" field.
| Scenario | State | Notes |
|---|---|---|
8. PRs
| PR | Title |
|---|---|
| #3792 | [shell] Read a run's errors and its job chain |
9. Review
| Comment summary | File | Decision | Notes |
|---|---|---|---|
10. Result
The shell reads a run's reasons and its whole job chain.
- `report_instances list` and `report_instances get <name>` state the run: its state, times, party, output message and output storage key.
- `report_error_events list` and `report_error_events by-report-instance-id <id>` return the run's reasons with scope, severity, subject, subject id, detail and time.
- `report_error_scopes list` returns the catalogue the reasons are grouped by.
- `batches`, `workunits by-batch-id <id>` and `results by-workunit-id <id>` carry the job chain, down to the result's outcome and error message.
Proven against a triggered Board Risk run. Instance 944fc6e3 recorded 33
errors; `by-report-instance-id` returned them (scope Trade, subject trade,
the missing mandatory id in the message, the exception type in the detail), and
the chain answered: instance to batch 89c05351, batch to workunit
1d4931f8, workunit to result cbc2a3e7 with outcome 3 and the engine's
message.
Two defects made this impossible before. Nothing registered the generated
report_error_event or report_error_scope command units, so every recipe for
a run's errors aborted with "Wrong command". The reporting service subscribed
only the counts read, so even a registered command reached no responder. Both
are fixed, and every reporting unit is registered now: 187 units across refdata
and reporting, with ores.reporting added to the composition check so an
unregistered unit fails the gate rather than a person's session.