Resiliency: failure in output bindings?

[ThomasVandenbon]

I've been going through your example code and I've been wondering about the following.

Inside the TransferCommandProcessor multiple CheckingAccountLine documents are being written to Cosmos via the CosmosDB-output binding of the TransferMoney-Azure Function. Additionally a TransferSucceededEvent is sent to EventHub.

What would happen if an error would occur in the processing of one of these output bindings?

I would assume the following:

• If the 2nd AddAsync on the Cosmos binding fails, you'd end up with the money being removed from one account, but not added to the other. I don't see any code path that will undo this document. In fact, if the transfer would be compensated via the CancelTransferCommand then money would be incorrectly removed from the receiving account.
• If the EventHub-binding fails at the end of the Azure Function execution (which I assume is possible?), then we'd never get a TransferFailedEvent or TransferSucceededEvent eventhough the transfer will have taken place (without a receipt). If this would cause a retry, then twice the intended amount would be transferred.

Could you clarify if my assumptions are correct?

[ThomasVandenbon]

Looking deeper, it seems the DurableOrchestrator only triggers compensations when IssueReceiptCommand fails. Am I right in thinking that the resiliency only applies to the IssueReceiptCommand?