Problem
When something fails, the user gets a transient #error banner and the
traceback goes to a log file they will never open. Dismiss the banner, or
reload, and the failure is gone: nothing records that it happened, and nothing
helps the user tell us about it.
#359 made the case already:
This is the difference between a bug report we can act on and one we cannot.
#343 took a screenshot, a reading of the transport clock, and a walk through
the engine source to get to a hypothesis, and it still is not confirmed.
#343 is the standing proof — its author guessed at a GPU cause and sent the
investigation the wrong way, because the app gave them nothing to paste.
Meanwhile the backend has written good evidence on every pipeline failure since
#277 — jobs/failed/<id>/error.txt carries the classified cause, device,
model, stage timings and a 40-line stderr tail — and no API ever served it.
The UI only ever had the one-line error_detail.
What it should do
Failures should land somewhere durable, and turning one into a bug report
should be one click:
- A notification card that survives a reload, for import, playback, export and
update failures.
- Opening it shows what failed and the technical detail before anything is
sent.
- A "Report on GitHub" button that opens the bug form pre-filled with version,
OS, install method, stage, device, model and the stderr tail.
The user still writes what they were doing and ticks the preflight boxes —
GitHub cannot prefill checkboxes, and "I searched for duplicates" should stay a
promise the reporter makes.
Constraint
Issues are public. The report must carry technical details only — no track
title, no source URL. The user can add either if it helps.
Problem
When something fails, the user gets a transient
#errorbanner and thetraceback goes to a log file they will never open. Dismiss the banner, or
reload, and the failure is gone: nothing records that it happened, and nothing
helps the user tell us about it.
#359 made the case already:
#343 is the standing proof — its author guessed at a GPU cause and sent the
investigation the wrong way, because the app gave them nothing to paste.
Meanwhile the backend has written good evidence on every pipeline failure since
#277 —
jobs/failed/<id>/error.txtcarries the classified cause, device,model, stage timings and a 40-line stderr tail — and no API ever served it.
The UI only ever had the one-line
error_detail.What it should do
Failures should land somewhere durable, and turning one into a bug report
should be one click:
update failures.
sent.
OS, install method, stage, device, model and the stderr tail.
The user still writes what they were doing and ticks the preflight boxes —
GitHub cannot prefill checkboxes, and "I searched for duplicates" should stay a
promise the reporter makes.
Constraint
Issues are public. The report must carry technical details only — no track
title, no source URL. The user can add either if it helps.