ubuntu
ManagePage: one failed update should not cancel all updates
If one presses update all and one of the updates can not be made because the app is running, the update all should still happen with the ones that are updateable (if this is a word)
Just a small update - the snapd API docs say:
POST /v2/snaps ... Fields ... transaction: optional string field, defaulting to per-snap if not present. If all-snaps is used, the action field will be performed such that the corresponding change will have a single transaction covering all the snaps. If in this case there is a failure for any snap, the state of all affected snaps will be fully reverted, even if for some snap the action has been successful. This field is valid for install and refresh actions. See Transactional updates for more details
So in principle it should be possible to refresh multiple snaps via a single API call and errors that occur during the refresh of an individual snap shouldn't affect the other ones. However, in practice that doesn't seem to work:
Example with two snaps that are up to date:
$ snap refresh steam signal-desktop
All snaps up to date.
Example with two snaps, where one is currently running:
$ snap refresh steam firefox
error: cannot refresh "steam", "firefox": snap "firefox" has running apps (firefox), pids:
6167,...
The first command creates a snap change, as expected, but the second one doesn't:
$ snap changes
ID Status Spawn Ready Summary
2621 Done today at 14:58 CEST today at 14:58 CEST Refresh snaps "steam", "signal-desktop": no updates
Possible workarounds
- Passing an empty list of snaps to snapd (has the same effect as running
snap refresh). In this case errors that occur while refreshing an individual snap will be silently ignored. - Refreshing each snap individually (as previously done in the community store). Besides known issues with that (polkit authentication would be invoked multiple times, unless we wait until the first snap in the list is refreshed, and loop through the remaining ones afterwards), we'd need to handle each transaction separately to track their progress and watch for possible errors.
Confirmed with the snapd team that this is indeed expected behavior. The per-snap transaction type affects only the transaction(s) that are spawned after initial checks. They recommend the same to options I posted above and plan to improve the verbosity of snap refresh in the future.
@d-loose great improvement with your latest pr!
polkit authentication would be invoked multiple times, unless we wait until the first snap in the list is refreshed, and loop through the remaining ones afterwards)
Beside that would eventually be a little bit slower I think this would also have the advantage of seeing the progress indicators of all the snaps individually. The polkit thing is not visible for the users so I don't think this should matter that much