-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RequestCancelExternalWorkflow Sample #240
base: main
Are you sure you want to change the base?
RequestCancelExternalWorkflow Sample #240
Conversation
return nil | ||
}) | ||
s.env.SetOnChildWorkflowCanceledListener(func(workflowInfo *workflow.Info) { | ||
childCancelInfo = workflowInfo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not get called, presumably because we are mocking the ChildWorkflow...but note that the SetOnChildWorkflowCompletedListener
does get called, so it is a little surprising (not obvious).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the go test suite code I think the current behavior is correct. Right now the workflow assumes the child WF will be blocked until it is signaled so when you call RequestCancelExternalWorkflow
you know it will cancel the child WF. In this test since you mock the child WF, the child WF will instantly complete so your call to RequestCancelExternalWorkflow
will not cancel the child WF since it is already complete (not running) so you don't get the callback.
s.env.SetOnChildWorkflowCompletedListener(func(workflowInfo *workflow.Info, result converter.EncodedValue, err error) { | ||
childCompletedInfo = workflowInfo | ||
}) | ||
s.env.OnRequestCancelExternalWorkflow(mock.Anything, childWorkflowID, "").Return(nil).Once() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You must assert on this if you are mocking a child workflow and want to verify the cancellation of it. The cancellation listener does not get called.
s.True(s.env.IsWorkflowCompleted()) | ||
s.NoError(s.env.GetWorkflowError()) | ||
//s.True(cancelRequestCalled) | ||
s.NotNil(childCancelInfo) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fails because the cancellation listener isnt invoked.
I was trying to figure out the best way to test cancellations of Child Workflows. In the past, only cancelling the context was possible so I thought I'd try out
RequestCancelExternalWorkflow
.I stumbled on some seeming inconsistencies I thought I'd highlight to verify whether a bug exists or not.
There are two tests:
Test_Cancel_NoMocky
which does not mock out ChildWorkflow execution. TheSetOnChildWorkflowCanceledListener
is invoked. It is noteworthy that usingOnRequestCancelExternalWorkflow
fails, which I suppose makes sense but we should make clearer in docs that this API is only for mocked ChildWorkflow calls.Test_Cancel_WithMocky
mocks theMyChild
workflow. TheSetOnChildWorkflowCanceledListener
is not invoked, though theSetOnChildWorkflowCompletedListener
is invoked. This seems inconsistent to me. I ack that when someone usesOnRequestCancelExternalWorkflow
they should Assert the expected call on that...however since tests evolve in projects and mocking is eventually introduced for children so the cancel listener no longer being called is hard to understand. We should at least call out that the listener is not called when using this API.This sample shows how to use the
RequestCancelExternalWorkflow
API.There are some nuances using this not very obvious (to me):
Unhandled Command
errors (appear in workflow history) when the ChildWorkflow future was not resolved. Doing a simple.Get
after callingRequestCancelExternalWorkflowExecution
fixed this.OnWorkflow
mock for workflows that do not have arguments...you must still pass in an argument (egmock.Anything
) or else theworkflowInterceptor
panics...seems like we are missing a check for params before spreading them somewhere.