I have workflow where only the first few activities can be canceled. The subsequent activities are not cancellable and should only run if the first few completed. My struggle is the case where the cancel request is sent during the subsequent activities (i.e. those that ignore the request). When this happens, even though all the activities run successfully, the workflow is reported as Canceled. I would expect (and need) it to report as Completed.
My current approach: I place the first few activities in a cancelation scope. When the scope completes, I check the scope’s isCancelRequested(). If it is false, I run the subsequent activities in a detached cancelation scope.
Is there a different approach I could take that would allow my scenario to report the workflow as Completed?
One follow up question. This might sound like a weird question, but could an interceptor be used to intercept the cancel request, issue a signal to the workflow, and stop the request propagation? The motivation for this is that our product will allow product extensions to add Temporal workflows (from any SDK). The product will have one API that will trigger cancelation of workflows.
From my reading of other posts in this area, SDKs such as Typescript will show workflows as completed if the activity doesn’t propagate the cancel request. Rather than requiring all temporal workflow extensions to our product (typescript, go, etc.) to implement a cancel signal handler, I would rather require that any Java SDK workflow implementer intercept the cancel request, issue the signal, and don’t progate the cancel request.
I tried this approach but ended up with the opposite problem. Recalling my scenario…
If I handle cancelation via a signal, I don’t see a way to get workflow to a status of Canceled when cancelation is acceptable and successfully processed. The workflow ends up in Completed. I tried getting the workflow (newUntypedWorkflowStub(Workflow.getInfo().getWorkflowId())) while in the workflow code and issue a cancel, but an exception occurs as the code is not in the workflow thread but a workflow method thread(?).