`cloudexec status --all` displays job as `cancelled` even if job is still running

[0xicingdeath]

cloudexec status output prior to running clean:

+--------+----------+---------+-----------------+----------+------+--------+---------------------+---------------------+--------------+-------------+------------+
| 242    | echidna  | running | 64.225.8.129    | 32768 MB | 16   | 200 GB | 2024-02-01 04:17:57 | 2024-02-01 04:22:01 | 4 minutes    | $0.5000     | $0.0339    |
+--------+----------+---------+-----------------+----------+------+--------+---------------------+---------------------+--------------+-------------+------------+

Command to clean asks whether or not to destroy droplet – response is u (i.e: neither y or n)

  - cloudexec-natchin (IP: 64.225.8.129) (Jobs: 242) created at 2024-02-01T09:18:56Z
destroy this droplet? (y/n)
u

cloudexec status --all output for job-242:

+--------+--------------------------------+--------------+-----------------+----------+------+--------+---------------------+---------------------+---------------------+-------------+------------+
| 242    | echidna                        | cancelled    | 64.225.8.129    | 32768 MB | 16   | 200 GB | 2024-02-01 04:17:57 | 2024-02-01 04:22:01 | 4 minutes           | $0.5000     | $0.0339    |
+--------+--------------------------------+--------------+-----------------+----------+------+--------+---------------------+---------------------+---------------------+-------------+------------+

[0xicingdeath]

Actually, I'm not sure anymore. Maybe it is just the table rendering incorrectly?

When I rerun cloudexec cancel, it does seem job-242 is still alive:

Existing cloudexec-natchin instance(s) found:
  - cloudexec-natchin (IP: 64.225.8.129) (Jobs: 242) created at 2024-02-01T09:18:56Z
destroy this droplet? (y/n)

despite its status in the cloudexec status --all being canceled

edit to add: I see the droplet still going on Digital Ocean so it does just seem like a rendering error

[bohendo]

Droplet deletion behaves as expected: we're deleting the droplet if we get y and doing nothing if we get anything else.

But the rest of the cancel command in main.go happily proceeds to remove ssh config and flag the droplet as cancelled in our state file regardless of user answers during droplet deletion. We need to return some context from ConfirmDeleteDroplets so later steps behave as desired.