Task: Parse the engine log when a run fails
Table of Contents
This page documents a task in the Rework the market data feeds into a market data service with adapters — the remaining work story. It captures the goal, current status, acceptance, and any notes or results.
1. Goal
A failed run's errors are the parsed structured messages, one per failure, with the trade id and type, not the raw transcript.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent story | Rework the market data feeds into a market data service with adapters — the remaining work |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-11-03 |
3. Acceptance
- The failure path runs the output through the canonical log reader and records the parsed errors.
- The run's message carries the summary; the Errors tab lists each structured failure.
- A failed run from the demo shows the parsed rows; the tests and gates are green.
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 |
|---|---|
| #4449 | [reporting] Record a failed run's log as rows, not a transcript |
9. Review
| Comment summary | File | Decision | Notes |
|---|---|---|---|
10. Result
A failed run's errors are now the parsed rows, not a transcript. Two defects were fixed in series: the compute wrapper uploaded its log only on success, so the reporting read a 404; and the failure path recorded the platform's raw message first, which the write-once recorder then protected, so the parsed rows could never land. The wrapper now writes its rows for every job that reached the engine (the structured log first, the text log otherwise), and the failure path records the log before it refuses; the run's message is one sentence that names the count and points at Errors.
Verified live on the rebuilt services: the Headline Position run
cd8082af-7f06-4365-a87e-3afc94a7a34d failed and its errors read 40 rows, 39
trade failures plus the run's pointer line, each with its trade id and the
engine's message; the run's message reads "The run's compute job failed with
outcome 3: Engine exited with code 255. Its log records 39 errors; the rows are
in Errors."
ores.reporting.core.tests 267 cases / 1499 assertions pass; compass lint
passes; check_component_drift reports no drift for reporting or compute-cpp.
A successful run remains unproven: the demo's package lacks
Input/simulation.xml, so the engine aborts before it prices, which is the
report-inputs task.