Repository navigation
feat(ingest): add cancel subcommand - #223
Conversation
POST /jobs/{id}/cancel marks an import cancelled without requiring a
rerun. The server uses a non-terminal 'cancelled' status to keep the
rerun in-flight guard active while the dltHub drain finishes.
- Add IngestCancelAck struct and cancel() client method
- Add `hotdata ingest cancel <id>` subcommand
- normalize_status: add 'cancelled' arm (was falling through to running)
- status_exit_code / poll_ingest: treat cancelled as terminal (exit 1)
so `status --wait` terminates cleanly instead of spinning forever
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| render(output, &machine, || { | ||
| use crossterm::style::Stylize; | ||
| let label = |l: &str| format!("{:<14}", l).dark_grey().to_string(); | ||
| println!("{}{}", label("status:"), util::color_status(&ack.status)); |
There was a problem hiding this comment.
nit: util::color_status (src/util.rs) has no arm for cancelled, so it falls through to the yellow "in-flight" color here and in one-shot status. But cancelled is now a terminal state (exit 1) and poll_ingest prints its message in red. Consider adding cancelled to color_status so the status cell doesn't render a settled job in the in-flight color. (not blocking)
| match normalize_status(status).0 { | ||
| "done" => 0, | ||
| "failed" => 1, | ||
| "failed" | "cancelled" => 1, |
There was a problem hiding this comment.
nit: the adjacent unit tests (status_exit_codes_close_over_stage_states, statuses_normalize_to_the_closed_set) cover every other status but not the new cancelled branch. Adding assert_eq!(status_exit_code("cancelled"), 1) and assert_eq!(normalize_status("cancelled"), ("cancelled", None)) would lock in this behavior. (not blocking)
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
Summary
hotdata ingest cancel <id>— callsPOST /jobs/{id}/cancelon the workerstatus --wait/trigger-import --waitto terminate cleanly when a job is cancelled (was spinning forever becausecancelledfell throughnormalize_statusto the running branch)cancelledexits with code 1, same asfailedBehaviour
Row-count progress (
1,234,567 rows loaded so far — orders: 800k, items: 434k) already surfaces in the--waitspinner via thedetailfield the worker now populates during loading — no additional CLI change needed.Test plan
hotdata ingest cancel <running-import-id>prints cancelled status and hinthotdata ingest status <id> --waitafter cancel exits 1 without spinninghotdata ingest cancel <unknown-id>surfaces the 404 from the workerhotdata ingest status <id>one-shot still exits 2 whilecancelled(non-terminal on the server side)