Initialize Device transaction incorrect "Done" status
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| snapd |
Triaged
|
Medium
|
Unassigned | ||
Bug Description
In a seeded classic image with a gadget whose prepare-device hook points at a serial vault URL that does not exist, the Initialize Device transaction finally (after the transaction times out) has a status of "Done".
Expectation: A final status that indicates the transaction is not completed and will therefore run again. For example: Error, or Hold, or something.
Note: Even though the Initialize Dev change ended up with a status of Done after it timed out, it did then in fact run again. Meanwhile, a corrected gadget had been installed pointing at the correct serial vault url. This new transaction also ended up with a status of Done, and this time a serial assertion was obtained.
Changes:
ubuntu@ubuntu:~$ snap changes
ID Status Spawn Ready Summary
2 Done 2017-10-
4 Done 2017-11-
ubuntu@ubuntu:~$ snap change 2
Status Spawn Ready Summary
Done 2017-10-
Done 2017-10-
Hold 2017-10-
.......
Request device serial
2017-10-
2017-11-
2017-11-
2017-11-
2017-11-
2017-11-
2017-11-
2017-11-
2017-11-
2017-11-
ubuntu@ubuntu:~$ snap change 4
Status Spawn Ready Summary
Done 2017-11-
Done 2017-11-
Done 2017-11-
| description: | updated |
| Changed in snappy: | |
| importance: | Undecided → Medium |
| Samuele Pedroni (pedronis) wrote | #1 |
| Kyle Nitzsche (knitzsche) wrote | #2 |
| Kyle Nitzsche (knitzsche) wrote | #3 |
| Changed in snappy: | |
| status: | New → Triaged |
| affects: | snappy → snapd |
I looked at our state machine again, we have the following transitions that end up in Hold, all related to trying to abort a change and its tasks:
i) Do ---> Hold (aborting a never started task)
ii) Doing ---> Abort -- (run tryUndo after current task run is terminated in a retry state or observed from outside the running goroutine) -> Hold (if the task doesn't support undo)
related transitions not ending in Hold:
iii) Done ---> Undo ---> Done (if the task doesn't support undo)
iv) Doing ---> Abort -- (we don't get to run tryUndo, the task terminates before then in a non-retry state) -> Undo --> Done (if the the task doesn't support undo)
so we never reach Hold from a task that was actually fully Done, so it seems it wouldn't be incorrect to assign to a Change that has combination of Done and Hold tasks the status Hold,
in fact it seems like the current decision is related to some confusion over time about transitions i/ii vs iii/iv and the actual use of Hold.