-
Notifications
You must be signed in to change notification settings - Fork 911
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
Add functional test for attaching callbacks in Nexus operations #7364
base: main
Are you sure you want to change the base?
Conversation
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.
I would add this test to the Go SDK too.
## What changed? <!-- Describe what has changed in this PR --> Make `OnConflictOptions.AttachRequestId` required if `OnConflictOptions.AttachCompletionCallbacks` is set. Change the callback state machine ID builder to use the request ID instead of the history event ID. ## Why? <!-- Tell your future self why have you made these changes --> Attaching a callback to a running workflow creates the `WorkflowExecutionOptionsUpdated` event, which can be buffered. In this case, the history event ID does not "exist" yet, and cannot be used to generate the callback state machine ID. ## How did you test it? <!-- How have you verified this change? Tested locally? Added a unit test? Checked in staging env? --> PR #7364 has tests that validates that this fix works. ## Potential risks <!-- Assuming the worst case, what can be broken when deploying this change to production? --> ## Documentation <!-- Have you made sure this change doesn't falsify anything currently stated in `docs/`? If significant new behavior is added, have you described that in `docs/`? --> ## Is hotfix candidate? <!-- Is this PR a hotfix candidate or does it require a notification to be sent to the broader community? (Yes/No) -->
6c1623d
to
280426b
Compare
## What changed? <!-- Describe what has changed in this PR --> Make `OnConflictOptions.AttachRequestId` required if `OnConflictOptions.AttachCompletionCallbacks` is set. Change the callback state machine ID builder to use the request ID instead of the history event ID. ## Why? <!-- Tell your future self why have you made these changes --> Attaching a callback to a running workflow creates the `WorkflowExecutionOptionsUpdated` event, which can be buffered. In this case, the history event ID does not "exist" yet, and cannot be used to generate the callback state machine ID. ## How did you test it? <!-- How have you verified this change? Tested locally? Added a unit test? Checked in staging env? --> PR #7364 has tests that validates that this fix works. ## Potential risks <!-- Assuming the worst case, what can be broken when deploying this change to production? --> ## Documentation <!-- Have you made sure this change doesn't falsify anything currently stated in `docs/`? If significant new behavior is added, have you described that in `docs/`? --> ## Is hotfix candidate? <!-- Is this PR a hotfix candidate or does it require a notification to be sent to the broader community? (Yes/No) -->
280426b
to
b2e092d
Compare
b2e092d
to
0e66c57
Compare
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.
Nothing blocking, feel free to address any comments and merge.
for i := 0; i < numCalls; i++ { | ||
wg.Add(1) | ||
workflow.Go(ctx, func(ctx workflow.Context) { | ||
defer wg.Done() | ||
fut := c.ExecuteOperation(ctx, op, input, workflow.NexusOperationOptions{}) | ||
var exec workflow.NexusOperationExecution | ||
err := fut.GetNexusOperationExecution().Get(ctx, &exec) | ||
if err != nil { | ||
output.CntErr++ | ||
var handlerErr *nexus.HandlerError | ||
var appErr *temporal.ApplicationError | ||
if !errors.As(err, &handlerErr) { | ||
retError = err | ||
} else if !errors.As(handlerErr, &appErr) { | ||
retError = err | ||
} else if appErr.Type() != "WorkflowExecutionAlreadyStarted" { | ||
retError = err | ||
} | ||
} else { | ||
output.CntOk++ | ||
} | ||
execOpCh.Send(ctx, nil) | ||
if err != nil { | ||
return | ||
} | ||
var res string | ||
err = fut.Get(ctx, &res) | ||
if err != nil { | ||
retError = err | ||
} else if res != "hello "+input { | ||
retError = fmt.Errorf("unexpected result from handler workflow: %q", res) | ||
} | ||
}) | ||
} | ||
|
||
for i := 0; i < numCalls; i++ { | ||
execOpCh.Receive(ctx, nil) | ||
} |
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.
Would have been much easier to follow if you put all of the futures returned from c.ExecuteOperation
into a slice, iterate over them and GetNexusOperationFuture().Get()
on them, signal, and then call Get()
on the futures.
No need for the goroutines, wait group, and channel IMHO since you don't care about getting the results concurrently.
} | ||
|
||
// number of concurrent Nexus operation calls | ||
numCalls := 5 |
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.
Why pass this around when you can just define it at the top of the test?
What changed?
Add functional test for attaching callbacks in Nexus operations
Why?
How did you test it?
Potential risks
Documentation
Is hotfix candidate?