Accessing parent cancellation scopes

Community Support
1

I am writing kind of a DSL layer over Temporal and I am trying to understand whether current cancellation scope is ultimately running detached. By “ultimately” I mean “current” scope is detached or it is running within parent scope that is detached. So far, the only hacky way that I see is by using private CancellationScopeImpl.parent, but is there a better way of doing that?

2

What is precisely the problem you are trying to solve?

3

Want to have “fire and forget” behavior for things that are scheduled as child workflows by adding “abandoned” parent close policy if it is started in detached scope.

4

I think it should be part of your DSL definition. Deriving this from the scope doesn’t really make sense. For example, if you need to guarantee cleanup before completing a workflow, then you don’t want abandoned parent cose policy even if the scope is detached.

5

I see you point, but it feels a bit awkward to additionally force set abandoned parent close policy for a thing that is already managed by the detached scope. One can argue either way but feels like it would be nicer for workflow and activity tasks to behave consistently. Activity that is happened to be running after parent workflow is completed will successfully complete its execution, but child workflow would be cancelled.

6

it feels a bit awkward to additionally force set abandoned parent close policy for a thing that is already managed by the detached scope

If a scope is canceled then it is not even possible to start a child workflow. So starting a child in a detached cancellation scope is required during cleanup. Note this is completely independent of the child parent close policy.

Activity that is happened to be running after parent workflow is completed will successfully complete its execution

This is not correct. Activity is considered canceled the moment the workflow completes.

7

If a scope is canceled then it is not even possible to start a child workflow. So starting a child in a detached cancellation scope is required during cleanup.

Yeah, absolutely. This is for scenario when scope it not yet cancelled. Something like

Async.procedure(() ->
  Workflow.newDetachedCancellationScope(() -> {
    Workflow.newUntypedChildWorkflowStub(
       "blahWorkflow", 
       ChildWorkflowOptions.newBuilder()
         .setWorkflowId("wfId")
         .build()).execute(...)
  }
)

This is not correct. Activity is considered canceled the moment the workflow completes.

Hm… it is not what I observe when using

Async.procedure(() ->
  Workflow.newDetachedCancellationScope(() -> activityStub.doSomething())
)

Activity above would complete even if workflow finishes before activity execution is complete. There is going to be warning in logs about activity being unable to report its status to Worklfow though.

8

Activity already running can learn about cancellation only through heartbeating or when trying to complete. This is what you witnessing. But it will not be executed if this activity has not started yet or waiting for a retry.