azure-samples / saga-orchestration-serverless Goto Github PK

The current implementation of the TransferMoney function may result in duplicate transfers when a software, hardware, or network error occurs during its execution. Each time the function is invoked by an Event Hub message, it writes two records to CosmosDB with debitFrom and creditTo information, using newly generated GUIDs as primary keys (TransferId). If there's a failure after a record is persisted to CosmosDB, the function will be retried, creating new debitFrom and creditTo records with distinct primary keys and causing the money in the "debitFrom" account to be deducted twice.

Steps to reproduce:

1. Invoke the TransferMoney function using an Event Hub message.
2. The function writes the debitFrom record to CosmosDB.
3. An error occurs after the record is persisted to CosmosDB (can be simulated through IDE breakpoint or throwing an exception).
4. Event Hub retries the TransferMoney function from the beginning.
5. The second execution creates new debitFrom and creditTo records with different primary keys and inserts them into CosmosDB.

Expected behavior:
When the TransferMoney function is retried, it should not create duplicate transfers, causing unintended deductions or credits to the accounts involved.

Actual behavior:
If a failure happens after the first AddAsync call causing the function host to crash and restart, the money has been deducted from the "from" account. When the TransferMoney is retried, it deducts the money from the "from" account a second time and credits the "to" account the first time. If the failure happens after both AddAsync calls, money will be deducted twice from the "from" account and credited twice to the "to" account.

Suggested fix:
Make the primary keys of the two records deterministic across retries. For example, use transactionId + transaction.AccountFromId as the primary key of the debitFrom record, and use transactionId + transaction.toAccountId as the primary key of the creditTo record. This way, no matter how many times AddAsync is called, only two records will be entered into CosmosDB, avoiding duplicate transfers.

Note: CosmosDBAsyncCollector.AddAsync makes adding/updating happen right away when it is called but does not wait until the user code region finishes. Even if these two records are added after the user code exits, if the function host crashes in the small window before checkpointing to EventHub to record a successful function call, a retry would still happen, causing two more records to be added to CosmosDb.

Hi folks,

I am following the step 1 in the getting started guide: which is the setting up the IaC.

Having the following error when running the github action:
Error: Failed to get existing workspaces: storage: service returned error: StatusCode=403, ErrorCode=AuthenticationFailed, ErrorMessage=Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.

any advice will be appreciated.

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?

Hi
After exception in CreateReceiptAsync Orchestrator produce again TransferCommand instead CancelTransferCommand because in CommandFactory.BuildCancelTransferCommand Header has:
nameof(TransferCommand)
instead of
nameof(CancelTransferCommand)
Fix:
#7