# Cancel Workflow Handling Questions

**URL:** <https://community.temporal.io/t/cancel-workflow-handling-questions/8793>\
**Category:** Community Support\
**Tags:** go-sdk\
**Created:** [July 10, 2023, 2:53pm UTC](https://community.temporal.io/t/cancel-workflow-handling-questions/8793 "2023-07-10T14:53:23Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![darewreck](https://avatars.discourse-cdn.com/v4/letter/d/c37758/32.png) [@darewreck](https://community.temporal.io/u/darewreck)\
**Post date:** [July 10, 2023, 2:53pm UTC](https://community.temporal.io/t/cancel-workflow-handling-questions/8793/1 "2023-07-10T14:53:23Z")

</div>

Hi,

Had the following questions:

1. Is there any guidance on how to validate clean up logic triggered from a Cancel workflow which is called in the defer(). The cleanup logic has some conditional logic check to see if certain activities were executed prior before executing. I looked at the sample go project and it’s not clear how the timing is handled. For example, in my use case the workflow executes activities A & B . When it cleans up, It executes activities D, E. In this case, activities D & E only executes if B has been executed before the cancel.

It’s not clear how to configure the test framework to trigger the cancel only after activity B is executed.

1. While testing end to end, I notice that when I handle the cancel request in the `defer`

```auto
newCtx, _ := workflow.NewDisconnectedContext(ctx)
options := workflow.ActivityOptions{
		StartToCloseTimeout: 2 * time.Minute,
		RetryPolicy: retryPolicy,
}
deleteHpaCtx := workflow.WithActivityOptions(newCtx, options)
err := tw.ExecuteActivity(deleteHpaCtx, p.act.CleanupActivity).Get(deleteHpaCtx, nil)

```

The `err` in this case outputs `canceled`. It’s not clear why this is the case since I created the new context with the `NewDisconnectedContext`. I don’t know where `canceled` comes from considering its triggered when extracting the results of the activity and it’s not something I return. It seems injected by the system

1. I also noticed that when you run activities in the `NewDisconnectedContext` for cancel, the errors don’t populate to the workflow UI. Is there a special way to report the error so the workflow fails if the clean up fails?

Thanks,  
Derek