Azure-functions-durable-extension: a termination call to an orchestrator doesn't terminate any sub-orchestrations it started

Created on 14 Feb 2018  路  11Comments  路  Source: Azure/azure-functions-durable-extension

terminating an orchestrator should also terminate the sub-orchestrators it has started but this is not the case.

dtfx enhancement needs-discussion

Most helpful comment

I'm starting to use DF in a more or less complex scenario, and this was driving me crazy!
Will have to redesign my architecture, since i was depending on other orchestrators. I will see if I can just have them as activities.

I think this is a very reasonable feature request, specially since the role of an orchestrator is to orchestrate!

All 11 comments

We might want to make this an optional behavior. Thoughts?

That makes sense. I could see where in some scenarios you might want to leave a sub-orchestrator running. Perhaps handle it as an optional parameter on the terminate method?

@simonporter what is the expected behavior in the Durable Task Framework? Should a terminate message terminate a parent orchestration and all it's children, or just the parent?

@cgillum did you ever hear back from @simonporter on how this works in the Durable Task Framework?

The current behavior in the default provider is that a terminate call on the parent will only terminate the parent, it does not propagate to the children.
It does look like a reasonable extension would be to add an option to also terminate sub-orchestrations. This might be an behavior not all providers can implement immediately.

I'm starting to use DF in a more or less complex scenario, and this was driving me crazy!
Will have to redesign my architecture, since i was depending on other orchestrators. I will see if I can just have them as activities.

I think this is a very reasonable feature request, specially since the role of an orchestrator is to orchestrate!

If we could have this https://github.com/Azure/azure-functions-durable-extension/issues/243
And if SubOrchestrations get passed it's parents instance id automatically, we could at least manually check for parent status and terminate accordingly.

@andreujuanc can you open a separate issue to track making the parent instance ID available to the sub-orchestrator? That might be a simple thing for us to add soon'ish.

Hi @cgillum, @simonporter just to confirm where did it land, the Orchestration Termination kills the sub-orchestrators as well? I can't find any documentation about that.

Hello, I hope this issue gets resolved as soon as possible.
for me, I made a workaround that worked locally but unfortunately didn't work on the Azure portal.
In the same function app, I Created another HTTP triggered function, and using the durable orchestration client I used the get status async method "IList instances = await client.GetStatusAsync();", then iterated over each instance where orchestration runtime status is either "running" or "continued as new" and called "client.TerminateAsync(instanceId);".

Was this page helpful?
0 / 5 - 0 ratings