Azure-functions-durable-extension: [Question] Get Child Orchestration Status?

Created on 10 Oct 2018  路  2Comments  路  Source: Azure/azure-functions-durable-extension

I've been using the "get instance status" API for getting status information for orchestration instances. It's been super-useful, but I've noticed that if I use sub-orchestrations and kick them off via a call to context.CallSubOrchestratorAsync, the status returned from the API doesn't include the status information for what happens during the sub-orchestration. When the sub-orchestration executes, I see a single entry indicating the whole status of the sub-orchestration, but I'm trying to figure out how to get at the inner status information. While the sub-orchestration is executing, the single status entry includes an "instanceId" which seems useful, but it subsequently disappears when the sub-orchestration completes.

Is there a recommended approach to get detailed status information for the entire orchestration flow?

documentation question

Most helpful comment

Thanks @kylepope for the question. We don't have a built-in way to get status for an orchestration and all related sub-orchestrations (it's not a capability provided by the underlying framework).

One strategy you can take to work around this limitation is to specify your own instance IDs when creating sub-orchestrations. See the CallSubOrchestrationAsync overload which takes an instance ID parameter. If you generate predictable sub-orchestration instance IDs - for example, derived from the parent orchestration ID (maybe append "-child1", etc.) then you can write a function which takes a parent instance ID and queries the status for both the parent and all the child instances, using whatever convention you decided on.

Would this work for you? I'm thinking this is probably something worth adding to our documentation.

All 2 comments

Thanks @kylepope for the question. We don't have a built-in way to get status for an orchestration and all related sub-orchestrations (it's not a capability provided by the underlying framework).

One strategy you can take to work around this limitation is to specify your own instance IDs when creating sub-orchestrations. See the CallSubOrchestrationAsync overload which takes an instance ID parameter. If you generate predictable sub-orchestration instance IDs - for example, derived from the parent orchestration ID (maybe append "-child1", etc.) then you can write a function which takes a parent instance ID and queries the status for both the parent and all the child instances, using whatever convention you decided on.

Would this work for you? I'm thinking this is probably something worth adding to our documentation.

Thanks @cgillum, awesome suggestion. That will work perfectly for my needs

Was this page helpful?
0 / 5 - 0 ratings