error event on the run’s stream, when a run ended because it was stopped mid-flight
— a POST …/stop, an operator abort, a dropped signal — and the abort surfaced as
the run’s ending. It is not a fault: nothing failed, someone (usually you) asked the
run to end. Only signed receipts settle and the rest of the reservation is released.
A clean stop more often ends as status stopped (a search-done with
stop: "stopped"); aborted is the ending when the interruption cut the run before
it could settle into that shape. Treat both the same way.
The shape
message is prose for humans and may change; program against code. Stream codes
are an open enum — handle an unknown code like
internal.
How to fix
- If you sent the stop: nothing to fix — this is the confirmation. Read what was
delivered before the stop from
GET …/rowsand the run’s receipts. - If you didn’t: check for a concurrent stop from another client or a dashboard action, and check the run’s timeline in the dashboard.
Reproduce it
Start a streamed run andPOST …/stop it while in flight (see
Streaming); an in-flight stop ends the run without starting
anything new.