Is there not an issue with the exchange sending funds back to the user? Notice , if the Ledger.transfer fails and the main canister traps before it can even call the switch (lets say some cycle error), then the book hashmap will not mark the addTokens and essentially the user will not get his funds he requested for withdrawal. I see tons of potential issues like this with any serivce that requires icp transfer and I’m wondering if I’m overthinking it and this is ignorable.
There is a system guarantee that an async call to another canister will always return. If the canister you are calling runs out of cycles, you still get an error back. So switch will always be called.
But I think that is assume your own canister always have cycles to process the reply. If your own canister runs out of cycles when the response from an async call comes back, then you are out of luck. Therefore it is critical to maintain a good cycle balance.
But I think that is assume your own canister always have cycles to process the reply. If your own canister runs out of cycles when the response from an async call comes back, then you are out of luck.
The IC actually reserves the amount of cycles needed to process the response in advance (and then refunds the excess if any), so this provides you a nice guarantee actually that the response can always be processed.
There is a system guarantee that an async call to another canister will always return. If the canister you are calling runs out of cycles, you still get an error back. So switch will always be called.
The IC actually reserves the amount of cycles needed to process the response in advance (and then refunds the excess if any), so this provides you a nice guarantee actually that the response can always be processed.
Oh okay this is useful to know. Thank you.
I think the bigger picture question for defi then is for synchronous calls after the intercanister awaits, is there anything else that could go wrong outside of your own faulty syncrhonous code besides cycle balance and memory storage? Or are those 3 things the only limiting factor at this point?
i.e. public func some_func():async ()
{
await async_call();
//_____good non erroneous synchronous code
var x = 1+4;
hashmap.put(123,134);
}
Essentially then is there any possible random errors that might cause the synchronous code to fail (given its written without error) such as some random concencus problem or something I cannot think of?
