Bug Description
cancel_jobs sends job ids to scancel 200 at a time and bails out of the loop on the first non-zero exit, so later chunks are never sent. do_cancel turns that into Cancel failed: ..., which presents a partial cancellation as a total failure. The usual cause of a non-zero exit is one id the user no longer owns or that already finished, which scancel reports per job while still cancelling the rest of the batch, so this is reachable any time a selection is slightly stale.
Steps to Reproduce
Select more than 200 jobs where one of them has already finished, then cancel. Or drive it directly with a scancel shim that logs each batch and exits 1 when it sees a specific id:
let mut ids = vec!["BAD".to_string()]; // already finished
ids.extend((0..499).map(|i| format!("{}", 90000 + i))); // live jobs
rt.block_on(cancel_jobs(ids));Expected Behavior
All three batches are sent, and the message says how many were cancelled and what went wrong with the rest.
Actual Behavior
scancel invocations: 1
batch of 200
returned: Some("scancel: Invalid job id BAD")One batch of 200 goes out, the other 300 ids are never sent, and the user sees Cancel failed. Their natural recovery, select everything and try again, fails exactly the same way.
System Information
sqwatch 0.2.0, source checkout at 4c594fb
Ubuntu 26.04.1, rustc 1.97.1
Running every chunk and collecting the failures, then returning the cancelled count alongside the errors, lets the flash say Cancelled 300 of 500, scancel: Invalid job id 12345. There is one caller, so it is one signature change. The success path needs the same treatment: it currently reports the number of jobs selected, not the number scancel actually cancelled.
Worth doing in the same change, and arguably mattering more than the reporting: the confirmation dialog shows only a count, so showing the first few ids would let someone notice they are about to cancel the wrong selection.
Bug Description
cancel_jobssends job ids toscancel200 at a time and bails out of the loop on the first non-zero exit, so later chunks are never sent.do_cancelturns that intoCancel failed: ..., which presents a partial cancellation as a total failure. The usual cause of a non-zero exit is one id the user no longer owns or that already finished, whichscancelreports per job while still cancelling the rest of the batch, so this is reachable any time a selection is slightly stale.Steps to Reproduce
Select more than 200 jobs where one of them has already finished, then cancel. Or drive it directly with a
scancelshim that logs each batch and exits 1 when it sees a specific id:Expected Behavior
All three batches are sent, and the message says how many were cancelled and what went wrong with the rest.
Actual Behavior
scancel invocations: 1 batch of 200 returned: Some("scancel: Invalid job id BAD")One batch of 200 goes out, the other 300 ids are never sent, and the user sees
Cancel failed. Their natural recovery, select everything and try again, fails exactly the same way.System Information
sqwatch 0.2.0, source checkout at 4c594fb Ubuntu 26.04.1, rustc 1.97.1Running every chunk and collecting the failures, then returning the cancelled count alongside the errors, lets the flash say
Cancelled 300 of 500, scancel: Invalid job id 12345. There is one caller, so it is one signature change. The success path needs the same treatment: it currently reports the number of jobs selected, not the number scancel actually cancelled.Worth doing in the same change, and arguably mattering more than the reporting: the confirmation dialog shows only a count, so showing the first few ids would let someone notice they are about to cancel the wrong selection.