because workunit messages already get more attention.

you’d see a “Cancelled: X” message, aligned with the existing `Starting`/`Completed` messages, and then you’d see another

Starting

message

@hundreds-breakfast-49010: between this and the other thing, this might be a cleaner solution

@hundreds-breakfast-49010: the actual fix should be a few lines.

@hundreds-breakfast-49010: the google results for “drop guard” aren’t great, but this is what i mean:

struct Guard(S);
impl Drop for Guard {
   fn drop(&mut self) {
       self.0.clean_up()
   }
}

… that thread is noisy. sorry…. ^ that’s all i meant.

…well, actually it’s useful-ish. it’s common with a drop guard for it to contain a Option: if you successfully complete the workunit, you

guard.thing_to_maybe_cleanup.take()

… then Drop only calls the workunit canceled if the value is still there.