If a call to my canister update method fails to execute due to reasons not related to my update method code (i.e. simple fast code, deterministic). For instance, if the sub-network is very saturated for a long time or all nodes go down. Is this possible?
If possible, then it is possible that my update method could have finished some initial instructions but not all of them. If these initial instructions do a remote call (e.g. ledger call to transfer some ICP) and the following, not executed instructions, are instructions to update local variables (note: example fromDEX example code). Then, the remote canister (e.g. the ledger in this example) and my canister called initially may have inconsistent information (e.g. the rollback logic in the DEX example is never executed due to a system malfunction). If this is the case, somehow I need to register exactly what instructions have been executed. how can I do that?
1 Like
A canister commits state whenever it makes an inter-canister call. If it fails after that, then it rolls back to that state right before the call. You can inspect the source code to figure out what exactly got executed.
1 Like
Thank you very much for your reply. Please, let me understand this in more detail:
Let’s assume the following sequence:
- User U call method M of canister DEX: DEX.M()
- DEX.M() calls method W of canister LEDGER and succeeds: LEDGER.W() returns OK
- DEX canister goes down and stops executing. So, it does not execute the instructions to update the local variables
At this point, in practical terms, how can user U “inspect” the source code and the state to figure out that LEDGER.W() was successfully executed but the local variables were not updated?
Hmm, I’m not sure a normal canister can just go down and stop executing (unless stopped). I thought smart contracts were supposed to be unstoppable due to the consensus algorithm. If one replica goes down, then the other replicas will continue running the canister.
1 Like