That’s not a functionality/base protocol concern, though. This concerns calling conventions and execution models, which the developer should be free to specify on his own. We aren’t on ethereum, where everything happens atomically, and it may or may not be intended to have transactional atomicity, depending on the specific problem to be solved.
The canister writer can specify a time limit for calls coming back.
This can be done now by saving the time of the call in the canister state and checking that time in the callback and trap if the callback came back past the time-limit.
I’m not disagreeing, I was just trying to make the point that how exactly it is implemented is not that important, as long as multiple high-level behaviour patterns can emerge from it, and the problem of rolling back canister changes in outer canisters if nested calls timeout, that comes from a specific mental model of how high-level calls should behave, but that model is up to the canister developer IMO. As long as the underlying primitives allow the implementation of multiple models, the IC protocol won’t have to concern itself with a specific high-level model for canister call behaviour.
The way the rust-cdk and the motoko-language do cross-canister-calls is with the await pattern. If a callback does not come back to the canister(that uses the rust-cdk or motoko) (due to a timeout or any reason) then the canister-method’s memory will leak and never clean up.
If a canister is written without the rust-cdk/motoko and passes function pointers as callbacks then a timeout can work but at that point let’s do the name-callbacks so that a canister can give a function-name as a callback and handle callbacks that come back after upgrades.
That is an interesting idea!
+1. Recently we got annoyed by inter-canister call for breaking the atomicity. We need more robust infra to enable the our Defi.
I’m hoping a couple design patterns emerge on how to properly rollback inter-canister calls.