A subnet running out of memory due to input/output queues filling up will not cause a canister to trap mid-execution. It would only cause synchronous outgoing call error results which the canister can handle without trapping and it would cause a canister to not be able to receive incoming calls at the method entry points but again would not cause a canister to trap mid-execution by something outside the canister’s control.
A canister (or a canister author/maintainer) is able to make sure that there is always enough cycles and also can check with the canister_balance api in case of trying to send cycles or create a canister with cycles. This is still within the canister’s control.
I think I know what is going on here. Even though there are no specific cases where a canister could trap mid-execution by something outside the canister’s control, you would still hold the assumption that it could happen. It looks to me like this is because there is no claim on the contrary anywhere in the protocol spec, so as the good engineer that you are, you assume the worst case. In this case however, that assumption is not held by DFINITY as a whole as the evidence by the ckBTC minter canister’s code shows (as spoken about in the last thread) where the ckBTC minter does rely on the guarantee that a canister cannot trap mid-execution by something outside the canister’s control and thereby does rely on the response guarantee of the ckbtc-ledger’s-response to make sure it mints 1:1 btc for ckbtc.
If you are now thinking about designing the scalable message model around the assumption that a canister could trap mid-execution by something outside the canister’s control, and therefore, the assumption that current responses are not guaranteed because if a canister can trap mid-execution by something outside the canister’s control, then that means that the trap can happen while handling a response, making it as if the response never reached the canister, then this would worsen the fragmentation even more. It is good that now this underlying question is being brought to the surface so we can settle this matter and create harmony between the canister implementors (ckBTC canister implementers) and the replica implementers (the execution team). The one location that is the authority of the contract between the canister implementors and the replica implementors is the ic interface-specification.
Hi @bjoern, and @mraszyk, Does the protocol guarantee that a canister will not trap mid-execution by something outside the canister’s or canister-maintainer’s control? Or does the protocol allow for the possibility of a canister to trap mid-exection by something outside the canister’s control?
There is a big difference between these two statements with far reaching consequences in different directions depending on which statement is correct.
Once the correct statement is chosen, it fits into the interface-spec as the single and final authoritative source of the contract between the replica implementers and the canister implementers.