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?
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.
when the callee explicitly rejects, it is not a trap (callee state will persist), and the caller will receive a reject message.
when the callee traps, callee state will rollback, and the caller will receive a reject message.
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.