Open MhAllan opened 2 years ago
This behavior is by design - the second "start" event for the sub-orchestration is considered duplicate and discarded.
Is there any reason you can't use a unique instance ID for the sub-orchestration?
@cgillum it is not duplicate, here is timeline
Is there any reason you can't use a unique instance ID for the sub-orchestration. As you see from my code, I am using the item Id (which is my partition key in cosmos db) as the sub-orchestrator Id. Reason is that I am trying to achieve ordered handling per partition.
It works if I don't await CallSubOrchestratorAsync
but all partitions are blocking until the currently running sub-orch finishes
I wonder if using durable entities might be a better option than sub-orchestrations. They may be better designed to handle this type of pattern: https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview#aggregator
I don't know @cgillum I am already over this problem I used different techniques but this needs fixing. thanks for suggesting =)
Description
In the code below I have this object
class Payment { string PaymentMethod }
. It is coming from CosmosDB to a singleton orchestrator which calls sub orchestrator. when I change the object in Cosmos DB, Cosmos DB triggers and also the singleton orchestrator. The sub orchestrator triggers as well for the first change. Now, if I change the object again while the sub orchestrator is busy then the sub orchestrator continues with the previous value and drops the new value event.Expected behavior
Actual behavior
Relevant source code snippets
Known workarounds
App Details
Environment