Can a Java workflow report "Completed" if cancelation isn't propagated?

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?

PS: I did find Workflow should be able to ignore CancellationFailure and finish successfully · Issue #896 · temporalio/sdk-java · GitHub which seems to confirm my observations. However it was deemed as working as designed. I am hoping that someone can re-direct my approach or suggest a workaround.

Thank you.

Is there a different approach

you could have client send a signal rather than workflow cancelation and have your signal handler cancel the activity cancellation scope if needed.

Yes, that came to me too after posting. I’ll give that a try. Thank you!

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.

Looking forward to your thoughts. Thanks!

I believe that an interceptor won’t address my problem since the interceptor is invoked after the history entry is created.

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(?).