Cancel/suspend long running step

[bddckr]

It looks like this project is the best thing since sliced bread, especially for my use case of having persisted long "tasks" running. So thanks for all the hard work over at least the last 3 years (according to GitHub) ❤️

I'm wondering how I could allow ongoing steps to be canceled or suspended. The one example I have in mind is a workflow that has to download a big file as one of the first few steps.

1. While it can take at least a few minutes (or hours) to download the file, I'd like to be able to suspend and later resume the workflow without having to restart the whole download.
2. If we in the meantime understand that we do not actually need to complete this workflow, I'd like to cancel the ongoing workflow without waiting for the ongoing download step to finish (as I would just throw away its result anyway).

I think the important bit is that the decision to cancel/suspend is done outside the workflow/steps.

---

I had a look at the docs, samples, source code and tests and I come to the following conclusions:

1. The existing cancellation support is only used to cancel ongoing steps/workflows when you stop the workflow host. As such this cannot be utilized (as is) to allow use case 1 above.
2. A workflow is getting locked to ensure only one thing (worker/node) acts on it at any given time. Thus it seems like it's a bad idea to just change the underlying persisted data to mark a workflow as suspended - the ongoing workflow execution will not know about that change anyway and happily continue running the step.

Let me know if any of this is wrong! 😄

---

Can anyone give any pointers as to how I could still support both use cases outlined above?

In the best case all my steps would just get a CancellationToken that signals for both suspension and cancelation: The outside that signals the token can then decide whether to terminate or suspend the workflow with the existing APIs in this library. The important thing is that it just needs to "stop executing" as then this library's APIs seem to be able to go through with the terminate/suspend API calls and ultimately change the persisted state for it as well.

I have a feeling this can be done completely in the application layer, without any changes needed to Workflow Core: I could inject my own IStepOrWorkflowCancellationSignaler or something. This could allow the running steps to basically grab a CancellationToken for their work, or subscribe to some callback/IObservable even. That seems very similar to how the event/activity support works actually! But as far as I can see all this functionality is only utilized between step executions, not while one is running. 🤔 Do I have to reimplement the distributed state storage, including proper locking for this to be usable, like Workflow Core does with events/activities?

I'm also open to any other ideas of course!

[bddckr]

ideally the steps should be short running and the workflow long running. If something is blocking on an external event, you could make it async with a wait for. https://github.com/danielgerlag/workflow-core/issues/672#issuecomment-709383644

That actually sounds like I'm wrong to make my download operation a step. Instead I should move it outside Workflow Core and just kick off the tasks outside the step and signal back into it? 🤔 That kinda matches what I outline above I believe - though I was only concerned with cancellation of the ongoing step above.

[bozelli]

Any news on that one? I have a similar problem when executing a long running process the user should have the ability to stop the workflow. I'd like to leverage the IStepExecutionContext.CancellationToken for that. But I could not make it work.

My goal is to stop an ongoing workflow with an exception and use Saga for roll back process if user has cancelled it.

Is there a way I can achieve that?