-
Notifications
You must be signed in to change notification settings - Fork 79
Add CLI command for Reset activity API #732
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -6,6 +6,7 @@ import ( | |
|
|
||
| "go.temporal.io/api/enums/v1" | ||
| "go.temporal.io/api/history/v1" | ||
| "go.temporal.io/api/serviceerror" | ||
| "go.temporal.io/sdk/client" | ||
| ) | ||
|
|
||
|
|
@@ -231,6 +232,43 @@ func (s *SharedServerSuite) TestActivityUnPause_Failed() { | |
| s.Error(res.Err) | ||
| } | ||
|
|
||
| func (s *SharedServerSuite) TestActivityReset() { | ||
| run := s.waitActivityStarted() | ||
| wid := run.GetID() | ||
| aid := "dev-activity-id" | ||
| identity := "MyIdentity" | ||
|
|
||
| res := s.Execute( | ||
| "activity", "reset", | ||
| "--activity-id", aid, | ||
| "--workflow-id", wid, | ||
| "--run-id", run.GetRunID(), | ||
| "--identity", identity, | ||
| "--address", s.Address(), | ||
| ) | ||
|
|
||
| s.NoError(res.Err) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Didn't mention it on the last review but I should have. Ideally these tests should confirm the invoked action actually occurs.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We don't return any values for that. No error indicates that the command was processed successfully. I don't want to write more complicated test - it will be a duplicate of existing functional tests. In actual functional tests I'm faling activity few times, then reseting, then calling DescribeWorkflow to confirm that number of attempts becomes 1.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How do you know this command did anything? Sometimes we do replicate functional tests in every place we do them to ensure end-to-end behavior. When these tests are written in each SDK (and the CLI is basically an SDK), we make sure the intended effect occurs, yes even if that technically is duplicated in each language. Compare with the other tests in this repo. We technically could just run a command and check error, but we often want more.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I know that this command reach the server and return no errors. Which means it was a valid call, and it was processed.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Not all of them, just confirm it did something, like the other tests in this repository. It should be really easy to describe the workflow and check pending activities or whatever is needed.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Unlike for example for updating activity there is no direct expected side effect - the response is empty. Even If the response was not empty - one may apply the same argument "what if I just return expected result directly without calling OSS".
In this case (just like in my functional test) for the proper testing I need to make activity fail few times, then make DescribeWorkflow call and verify that the number of attempts is greater then 1.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, it'd basically be a functional test that resets after attempt > 1 and confirms it goes back to 1. You don't have to provide full coverage like you do where the implementation is, but at least one end-to-end assertion is worth it. We will surely be writing this same functional test for every SDK we provide this high-level activity reset call on.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Which already exist.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is a need and we do these kinds of end-to-end tests in other tests in all of our SDKs (which includes the CLI). Right now if the CLI code did nothing, this assertion would pass. Or if it did something but as a developer you may have missed actually making the gRPC call, you'd never know. Even with the next test testing for failure, you don't even know what failure it might hit. Lets validate at least some side effect occurred.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, talked offline. I will make a change to make a check that some result (of proper type) is coming from server |
||
| // make sure we receive a server response | ||
| out := res.Stdout.String() | ||
| s.ContainsOnSameLine(out, "ServerResponse", "true") | ||
|
|
||
| // reset should fail because activity is not found | ||
|
|
||
| res = s.Execute( | ||
| "activity", "reset", | ||
| "--activity-id", "fake_id", | ||
| "--workflow-id", wid, | ||
| "--run-id", run.GetRunID(), | ||
| "--identity", identity, | ||
| "--address", s.Address(), | ||
| ) | ||
|
|
||
| s.Error(res.Err) | ||
| // make sure we receive a NotFound error from the server` | ||
| var notFound *serviceerror.NotFound | ||
| s.ErrorAs(res.Err, ¬Found) | ||
| } | ||
|
|
||
| // Test helpers | ||
|
|
||
| func (s *SharedServerSuite) waitActivityStarted() client.WorkflowRun { | ||
|
|
||
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.
Not sure users really need this information and not the biggest fan of adding user-facing information only needed for tests, but this does technically confirm server response so I guess good enough.