In Ethereum it’s simple: a call either executes fully or not at all. But in IC we have multiple “checkpoints” at which state is written and is never reverted to state before a checkpoint. Correct? So, in Ethereum we don’t need a data consistency strategy (except of fixing reentrancy vulnerabilitie…

If your canister update call makes no downstream calls of its own, then the call will complete atomically, even if it takes multiple rounds to do so. If you do make downstream canister calls (whether to local or remote canisters; or even back to the canister itself) then execution is suspended until…

If there is a modification made to a canister, you will receive back a request_id. You can then make a request_status call to the IC with that request_id, and determine whether that change has a successful status, a rejection, or an error. Of course, agents like agent-js or agent-rs will do this for…

You may want to look up SAGA roll back and strategies for architecting your system around it in asynchronous systems. This comes into play when you have multiple canisters invovled.

@anon74414410 @free @skilesare Honest question: Am I missing something? I feel like the initial premise is not addressed simply enough. AFAIK If i send a message to ONE canister, it either executes completely or not. Checkpoints, rounds, multiple canisters, etc… that is all ancillary. Possible I…

But what if my method should do several IPC payments (calling the Ledger canister)? Payments can’t be cancelled. Should I lay aside all the payments as the last step, because after a payment I can’t do a rollback? Do I now understand this issue fully, or you have something to add to my knowledge?

[image] diegop: I feel like the initial premise is not addressed simply enough. AFAIK If i send a message to ONE canister, it either executes completely or not. Checkpoints, rounds, multiple canisters, etc… that is all ancillary. If that canister doesn’t make any downstream canister calls, th…

[image] free: ICP ledger calls are idempotent. How so? They transfer money. Calling two times transfers money two times. That’t not idempotent.

This transfers money. And if called twice, transfers money twice! ledger.transfer({ memo = 0; amount = toAuthor; fee = 10000; from_subaccount = ?Principal.toBlob(userId); to = author });

I seem to remember hearing that. I may well be wrong about it. My apologies. Looking at the API, it does look as if there is no nonce or anything that may uniquely identify a specific transfer.

What is the strategy for "complete" calls?

Developers

skilesare May 14, 2023, 11:53am 18

The ledger working group will soon be taking up Batch Transfers - ICRC4 to try to address some of this.

Topic		Replies	Views
Consensus and inter-canister calls Developers	12	3223	October 29, 2020
The biggest problem with the IC - InterCanister Calls Developers	26	3061	July 28, 2022
Why does the ledger canister need to maintain a blockchain on top of the subnet's blockchain instead of only storing balances? Developers	9	615	May 7, 2022
Question about Message Guarantees Developers	20	1001	July 24, 2023
What are good patterns to manage state across several canisters? Regarding non-atomicity Developers	11	474	November 25, 2022

What is the strategy for "complete" calls?

Related topics