-
Notifications
You must be signed in to change notification settings - Fork 825
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
Reset for workflows without completed tasks #665
Conversation
1d8b6bc
to
996dcc5
Compare
for _, e := range be.Events { | ||
eid++ | ||
if e.GetEventId() != eid { | ||
s.Fail(fmt.Sprintf("inconintous eventID: %v, %v", eid, e.GetEventId())) |
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.
[Nit] non-contiguous or non-continuous. Also, it is useful to add expected: and got: to the error message
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.
also, how could this happen?
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.
also curious when this would actually happen given we are the ones creating this mocked out data structure in the first place? We could have just assigned the eventTime variable inline for each event as well
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 can only happen if something is messed up in the reset logic in a way that creates gaps in event IDs. We do this check in other tests so it's there for consistency reasons.
Looks good 👍 |
This PR addressed an issue described in #494 allowing users to reset workflows without completed tasks.
In case if there is no completed task reset would use next event after workflow task scheduled event as a reset point.
It allows us to perform a reset on workflows that were unable to make any progress due to worker related issues.
Note that due to change in semantics two CLI parameters responsible for reset types were renamed: