Azure-functions-durable-extension: [Feature] Ability to cancel in-flight activities / sub-orchestrations when terminating parent

[sam-piper]

We've built a few ETL processes using Durable Functions that fan-out to thousands of activities. If we find a problem anywhere, we still generally have to wait for all child functions to finish execution, even if we terminate the parent orchestration directly (which is related to #153 but I'm including activities as well here).

It would be really useful and save a lot of time for us to be able to gracefully cancel OR abort child functions based on a parent instance being terminated. I could envisage this working (hypothetically) in a couple of ways:

1. Inject CancellationToken into activity / sub-orchestrator function signatures, so that function code can check for cancellation on this token whenever possible. This also supports opt-in to the feature when required, similar to ILogger injection.
2. Abort execution immediately by throwing a specific exception type on the underlying thread running the child code (OperationCanceledException or similar) - this might require different high-level operations on the client API (eg TerminateAsync with new options to mimic cancel vs abort semantics)

These are common approaches that I've seen before for cancelling / aborting long-running jobs. It would be great to understand if this is something on the roadmap for delivery, as it is something missing that would be trivial to do in standard .NET apps.

Additionally, for fan-out scenarios, if the parent instance is terminated and a child activity has not been executed yet, it should just be removed from queues and not executed at all.

Having the ability to abort functions as quickly as possible becomes particularly valuable when the work being performed could be very damaging to a business (eg, accidentally mailing confidential information to the wrong group of users).

[lukasvosyka]

@cgillum Any news on this topic? Is there an ETA? We are doing also running some ETL on huge datasets and would like to have the option to stop activities that are currently awaited by the orchestration, when the orchestration gets terminated.

[cgillum]

We've had some internal discussions about this, but there is no ETA yet. Until we have something, the workaround would be to use a background thread to periodically poll the status of the parent orchestration to see if it was terminated.

[olitomlinson]

@cgillum +1 for this please

[vany0114]

+1

[pkarda]

It'd be great +1