Child Workflow Cancelling Despite Abandon Policy

Community Support
,
1

Here is the implementation of the parent workflow:

func CompleteAssetDrop(ctx workflow.Context, params CompleteAssetDropParams) (uuid.UUID, error) {
	parentId := workflow.GetInfo(ctx).WorkflowExecution.ID

	wo := workflow.ChildWorkflowOptions{
		WorkflowID:        parentId + "-aggregation",
		ParentClosePolicy: enums.PARENT_CLOSE_POLICY_ABANDON,
	}
	ctx = workflow.WithChildOptions(ctx, wo)

	aggregateParams := AggregateAssetDropParams(params)

	var distroId uuid.UUID
	err := workflow.ExecuteChildWorkflow(ctx, AggregateAssetDrop, aggregateParams).Get(ctx, &distroId)
	if err != nil {
		return uuid.Nil, err
	}

	wo = workflow.ChildWorkflowOptions{
		WorkflowID:        distroId.String(),
		ParentClosePolicy: enums.PARENT_CLOSE_POLICY_ABANDON,
	}
	ctx = workflow.WithChildOptions(ctx, wo)

	completeParams := CompleteDistroParams{
		UserID:   params.UserID,
		EscrowID: params.EscrowID,
		DistroID: distroId,
	}

	err = workflow.ExecuteChildWorkflow(ctx, CompleteDistro, completeParams).Get(ctx, nil)
	if err != nil {
		return uuid.Nil, err
	}

	return distroId, nil
}

This workflow I’m executing as a cron workflow (not necessarily relevant). My second child workflow sleeps for a long period (3 mins). What I want to happen is that if this parent workflow is cancelled, I would still like the child workflow to complete. I read that PARENT_CLOSE_POLICY_ABANDON would prevent the cancellation being passed down, but in practice the child workflow cancels.

Is this because the workflow context that I’m passing in is getting cancelled? Should I be passing in a new workflow context?

Thanks in advance!

1 Like
2
1 Like
3

I read this solution, and it isn’t exactly what I’m looking for. This is starting an async workflow, I want to start a workflow synchronously that won’t transfer the cancellation down if the parent is cancelled. If this isn’t possible, then I suppose an asynchronous workflow will do.

4

If you want to abandon, why wait for the child workflow execution result? Instead of .Get() consider .GetChildWorkflowExecution().Get() which will inform you of child workflow start but not complete.

If your only goal is to not have the context cancellation propagate, yes, you need a new context + abandon. See NewDisconnectedContext. But your code as is will still wait on child workflow completion, so you’ll have essentially swallowed and ignored the cancellation if you wait on a child workflow’s result regardless of cancellation sent (which is sometimes desirable for a short period of time e.g. in cleanup cases, but then you should still return the original cancel error so the parent can properly be marked cancel).

5

The primary reason that I don’t want the purely abandon is that the parent context is being run as a cron workflow. I want the recurring workflow to be cancellable, but I want the child workflow to finish its execution. I believe you describe exactly what I’m hoping for in that, I want the cancellation to be swallowed until the child finishes. This issue is resolvable with schedules (which I can’t wait for), but not with cron workflows.

6

For anyone else potentially hitting this issue:

The solution I ultimately went with is creating an additional workflow that is solely responsible for the executing the child task. This additional top-level workflow is given the cron schedule and the child workflow is then executed entirely asynchronously as described above. It can then be cancelled, thus cancelling the schedule, but also ensuring that and child workflow finishes its execution.