I propose a change of the protocol that would allow to upgrade several canisters as one atomic operation.
This is useful for seamless upgrading an app that consists of several canisters without interruption or worse bugs of the app working.
The alternative solution is “fine-tuning” the app components and the order of upgrading (BTW, DFX apparently doesn’t support specifying in which order upgrades happen) to work well during the time of an upgrade.
To achieve the nearly the same with the current system:
-stop all canisters
-upgrade them
-start all canisters
This usually handled with scipts that call dfx to upgrade one single canister at a time
There is no atomic operation across multiple canisters.
To understand why this may be a problem, imagine a simple application consisting of 2 canisters, something like a backend and a DB. The DB is dumb, it applies single mutations; the backend combines multiple such DB operations into a transaction, relying on guaranteed response delivery to retry each step until it succeeds (or to roll back earlier steps).
Now if the backend is in the middle of a 2-step transaction and this “atomic multi-canister upgrade” puts both canisters into the Stopping state, the backend will be unable to either roll forward with the second step of the transaction (because the DB is immediately rejecting any requests) or to roll back the first step (same reason). But at the same time, it is unable to stop because it has this open call context that never terminates.
You’ve just deadlocked your application. Or at least made it un-upgradeable.