Hi,
Had the following questions:
- 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.
- While testing end to end, I notice that when I handle the cancel request in the
defer
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
- 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