Hello, I was wondering if what I’m doing is correct in my workflow code:
// ctx -> workflow.Context
cancelCh := workflow.GetSignalChannel(ctx, "cancel")
cancelCtx, cancel := workflow.WithCancel(ctx)
canceled := false
selector := workflow.NewSelector(ctx)
selector.AddReceive(cancelCh, func(c workflow.ReceiveChannel, _ bool) {
canceled = true
cancel()
})
selector.AddFuture(workflow.ExecuteActivity(cancelCtx, "MyActivity"), func(f workflow.Future) {})
selector.Select(ctx)
if canceled {
// shall I await the selector again for the future if I'm not going to use the result?
return nil
}
Are there any potential problems with leaked resources if I don’t explicitly wait for the future when I know that a cancellation has been received? Will the workflow activity stop executing as expected when its context is canceled, or do I need to explicitly do selector.Select(ctx) again in the branch where canceled == true?
I also noticed that there is an activity option called WaitForCancellation. Can you briefly explain what’s its purpose, as I can’t really understand it from the documentation?
Hello, I was wondering if what I’m doing is correct in my workflow code
Kinda. From ExecuteActivity docs, that will send a cancel to the activity properly.
But assuming your code is the actual code, activities are automatically cancelled on workflow completion, you don’t have to explicitly cancel them. Also, workflows can be cancelled themselves with a client call, you don’t have to use a signal.
Are there any potential problems with leaked resources if I don’t explicitly wait for the future when I know that a cancellation has been received?
Nothing is “leaked”, workflows clean themselves up after completion. Waiting for the future or not does not affect the activity.
Will the workflow activity stop executing as expected when its context is canceled
That depends on whether your activity respects cancellation of its context. But yes, its context is cancelled.
I also noticed that there is an activity option called WaitForCancellation. Can you briefly explain what’s its purpose, as I can’t really understand it from the documentation?
When cancelling an activity and then calling Get on the future, you would get a cancelled error without waiting on whether the activity actually completed when it was cancelled via its context. Setting this to true makes sure it does wait.
Some workflows may want to know when an activity is actually complete after being sent a cancellation before continuing on (e.g. if one activity needs to cleanup some resources before another is run).
Very informative answer, thanks @Chad_Retz
No, this is not my actual workflow code - I need to execute cleanup activities, thus I’m using a signal. I think I prefer that over working with detached workflow contexts, as terminating a workflow via client actually works as an immediate termination.
Sorry for not making that clearer, but in terms of “leaking resources” I was mainly referring to whether or not running activities will actually receive cancelation during the cleanup phase. We will be running lots of workflows, and I don’t want workers to spend unnecessary time working on canceled activities - it was unclear to me if I had to execute future.Get on a canceled future in order to properly cancel its underlying activity. Can you confirm that particular case as well?
We will be running lots of workflows, and I don’t want workers to spend unnecessary time working on canceled activities
Internally, activities are told whether they are cancelled during heartbeats. So make sure all activities heartbeat. This is not any extra worker work so long as your activities react properly to their context being cancelled.
it was unclear to me if I had to execute future.Get on a canceled future in order to properly cancel its underlying activity. Can you confirm that particular case as well?
Waiting for the future or not does not affect the activity. You do not have to wait on an activity future for the activity to receive its cancellation.
Thanks again! I will make sure I’m setting up frequent heartbeats.