Skip to content

Default LatestTime to Now in ListOpen/CloseWorkflowExecutions #641

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.

Sign up for GitHub

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

Merged
merged 4 commits into from
Jul 31, 2020
Merged

Default LatestTime to Now in ListOpen/CloseWorkflowExecutions #641

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
6027c39
Default LatestTime to Now in ListOpen/CloseWorkflowExecutions.
alexshtin Jul 30, 2020
d888226
Use year 2100 instead of time.Now.
alexshtin Jul 30, 2020
921087a
Merge branch 'master' into feature/default-latest-time
shawnhathaway Jul 31, 2020
f1ef3a2
Merge branch 'master' into feature/default-latest-time
alexshtin Jul 31, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions service/frontend/workflowHandler.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2343,6 +2343,10 @@ func (wh *WorkflowHandler) ListOpenWorkflowExecutions(ctx context.Context, reque
return nil, wh.error(errStartTimeFilterNotSet, scope)
}

if timestamp.TimeValue(request.GetStartTimeFilter().GetLatestTime()).IsZero() {
request.GetStartTimeFilter().LatestTime = timestamp.TimeNowPtrUtc()
Copy link
Contributor

@shawnhathaway shawnhathaway Jul 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Time.max() instead of Time.now() because of possible clock skew?

Copy link

@markmark206 markmark206 Jul 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i wonder if it might also make sense

  • to have the frontend just leave the values as is, and
  • to let whoever is actually handling the request to interpret IsZero values as "no upper bound", and produce the data accordingly.

Copy link
Contributor Author

@alexshtin alexshtin Jul 31, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Whoever" is persistence layer and we have 4 different calls to it. I will have to modify it in 4 places, or just one (here). I agree frontend handler is not a best place for it. Although all our validation/default logic is in frontend.

}

if timestamp.TimeValue(request.StartTimeFilter.GetEarliestTime()).After(timestamp.TimeValue(request.StartTimeFilter.GetLatestTime())) {
return nil, wh.error(errEarliestTimeIsGreaterThanLatestTime, scope)
}
Expand Down Expand Up @@ -2439,6 +2443,10 @@ func (wh *WorkflowHandler) ListClosedWorkflowExecutions(ctx context.Context, req
return nil, wh.error(errStartTimeFilterNotSet, scope)
}

if timestamp.TimeValue(request.GetStartTimeFilter().GetLatestTime()).IsZero() {
request.GetStartTimeFilter().LatestTime = timestamp.TimeNowPtrUtc()
}

if timestamp.TimeValue(request.StartTimeFilter.GetEarliestTime()).After(timestamp.TimeValue(request.StartTimeFilter.GetLatestTime())) {
return nil, wh.error(errEarliestTimeIsGreaterThanLatestTime, scope)
}
Expand Down