-
Notifications
You must be signed in to change notification settings - Fork 214
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
Dedup duplicate update IDs for test environment #1695
base: master
Are you sure you want to change the base?
Dedup duplicate update IDs for test environment #1695
Conversation
internal/internal_workflow_test.go
Outdated
@@ -1406,6 +1406,19 @@ type updateCallback struct { | |||
accept func() | |||
reject func(error) | |||
complete func(interface{}, error) | |||
env *TestWorkflowEnvironment |
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.
Hmm so this class is not for users, this whole file is for testing since it is post-fixed with *_test.go
. The logic can't be in the updateCallback as we take an impl. from user. The logic needs to be in (env *testWorkflowEnvironmentImpl) updateWorkflow
. We could potentially add a wrapper around the user interface. Does that make sense?
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.
Is user
in this context referring to the user of the test suite?
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 whole file is for testing since it is post-fixed with *_test.go. The logic can't be in the updateCallback as we take an impl. from user
And would it be accurate to rephrase this as "we need to implement this within the test suite, not the individual test logic. updateCallback
is a test specific implementation"?
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.
We could potentially add a wrapper around the user interface.
What interface are you referring to here? updateWorkflow
?
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.
Is user in this context referring to the user of the test suite?
Yeah
And would it be accurate to rephrase this as "we need to implement this within the test suite, not the individual test logic. updateCallback is a test specific implementation"?
yeah, exactly
What interface are you referring to here?
UpdateCallbacks
}, 0) | ||
|
||
env.RegisterDelayedCallback(func() { | ||
env.UpdateWorkflow("update", "id", &updateCallback{ |
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.
What if this update is sent before the first update completes?
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.
good point, added a mutex to the map to ensure the 2nd update must wait for the 1st update to complete
What was changed
Added functionality in test environment to cache update
Why?
Match non-test behavior
Checklist
Closes Workflow Update in Test Environment should dedup updates by ID #1638
How was this tested:
new test written
Any docs updates needed?