`ic_cdk::call` When can I trust a message was successfully enqueued

I’m writing up some inter-canister 2PC code. For now, I need to guarantee that the message sent via ic_cdk::call is enqueued at the destination canister for processing. Can ic_cdk::call panic or trap? Or, is the full range of failures captured by the RejectionCode?

Is there a way to not necessarily await a result. But, be assured that my message is enqueued?

1 Like

Your target canister may be on another subnet, and there are many reasons that a message could get sent but end up getting rejected eventually, e.g., not enough cycles, queue too full, etc.

If you want delivery guarantee, the only way to do it is await a result.

Gotcha. Can the call trap or panic?

Making a call could trap according to the spec if there is insufficient cycle.

A couple things to note:

  1. when the callee explicitly rejects, it is not a trap (callee state will persist), and the caller will receive a reject message.
  2. when the callee traps, callee state will rollback, and the caller will receive a reject message.
  3. the caller after receiving the reject message will be executing the callback it previously registered for this call, and it may choose to return to its caller by another reject or reply, or trap.

Hope it helps!

3 Likes