Skip to content
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 schedule rpc handlers #2857

Merged
merged 6 commits into from
May 26, 2022
Merged

Add schedule rpc handlers #2857

merged 6 commits into from
May 26, 2022

Conversation

dnr
Copy link
Member

@dnr dnr commented May 17, 2022

What changed?
Add handlers for the frontend schedule-related rpcs.

Why?
Implementation of new scheduled workflow functionality.

How did you test it?
Manual testing, will write integration tests next.

Potential risks

Is hotfix candidate?

@dnr dnr requested a review from a team as a code owner May 17, 2022 03:36
}

// Returns the schedule description and current state of an existing schedule.
func (wh *WorkflowHandler) DescribeSchedule(ctx context.Context, request *workflowservice.DescribeScheduleRequest) (_ *workflowservice.DescribeScheduleResponse, retError error) {
return nil, serviceerror.NewUnimplemented("todo")
defer log.CapturePanic(wh.logger, &retError)
Copy link
Member

Choose a reason for hiding this comment

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

any idea what is typical latency for DescribeSchedule?

Copy link
Member Author

Choose a reason for hiding this comment

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

in local testing it's been "fast enough". when it has to do a refresh it is slightly noticeable to me compared to the no-refresh case, so I'm guessing maybe 50-100ms more?

Comment on lines 3577 to 3580
// TODO: should we respect this here?
if wh.config.DisableListVisibilityByFilter(namespaceName.String()) {
return nil, errNoPermission
}
Copy link
Member

Choose a reason for hiding this comment

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

hmm, i think the reason we have that dynamic config is because the cassandra secondary index would bring down cass cluster if the data is too big. We probably should honor that setting. But maybe we should have clear error message or error logging to indicate that setting is the reason the request is failing. Otherwise, people won't be able to find out why it is failing.
Later, we should really get rid of cassandra visibility store.

Copy link
Member Author

Choose a reason for hiding this comment

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

I changed the error message to be more specific

Comment on lines 3600 to 3601
// TODO: is this correct? where does search attribute mapping happen?
SearchAttributes: ex.GetSearchAttributes(),
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

turns out it happens inside the ES visibility manager, and the other visibility stores don't support search attributes so they don't do it

Copy link
Member

Choose a reason for hiding this comment

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

which is not a good example of responsibility separation and needs to be changed one day.

@dnr dnr merged commit 3beaf63 into temporalio:master May 26, 2022
@dnr dnr deleted the schedpr7 branch May 26, 2022 19:41
Sushisource pushed a commit to Sushisource/temporal that referenced this pull request Jun 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants