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

Support the new versioning API #1494

Merged
merged 27 commits into from
Jun 7, 2024
Merged

Support the new versioning API #1494

merged 27 commits into from
Jun 7, 2024

Conversation

antlai-temporal
Copy link
Contributor

What was changed

This is a PR to support the new versioning API in the SDK-go that combines other (partially) reviewed PRs in the versioning-2
branch. In particular:

#1453
#1431
#1432
#1429
#1470

This PR will remain in draft mode until we can automate integration tests with CI, which requires a new docker image of the future server 1.24 (or a release candidate) for ubuntu, and a new CLI for mac/windows. Currently, all the integration tests pass using a local, up-to-date server (ubuntu).

However, I would appreciate early feedback to minimize delay on this important pre-release feature. Thanks for your help!

Checklist

  1. Closes
    Support the new versioning API #1420

@antlai-temporal antlai-temporal requested a review from a team as a code owner May 29, 2024 07:55
@antlai-temporal antlai-temporal marked this pull request as draft May 29, 2024 07:59
client/client.go Outdated Show resolved Hide resolved
client/client.go Outdated
// (index 0). If the given index is too larger the rule will be
// inserted at the end of the list.
// WARNING: Worker versioning is currently experimental
VersioningOpInsertAssignmentRule = internal.VersioningOpInsertAssignmentRule
Copy link
Contributor

Choose a reason for hiding this comment

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

Generally initialisms in Go prefer constant case so either op or OP. I would prefer Operation here since op could be operation or option and without reading the docs I can't tell. @cretz any thoughts?

https://google.github.io/styleguide/go/decisions#initialisms

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was mostly following what we had with the old versioning, e.g., BuildIDOpAddNewIDInNewDefaultSet. I guess that strictly speaking Op is not an initialism, it is just an abbreviation, but we could make it OP. My only concern is that in the middle of a word sometimes it is harder to "parse", i.e., VersioningOPAddRedirectRule vs VersioningOpAddRedirectRule , is "OPA" or "PA" (you need look-ahead :-) ).

About the confusion with Options, we always have "Options" with no shortcuts, so that is less confusing with "OP" for operations. I worry if we extend operations it is just too much typing, e.g., VersioningOperationDeleteRedirectRule...

Anyway, happy to change things, @cretz comments?

Copy link
Member

Choose a reason for hiding this comment

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

I have no strong opinion. Operation works for me. I do appreciate how we're prefixing all of these w/ the same prefix though.

// - Backlog info for Workflow and/or Activity tasks
// When not supported by the server, it returns an empty [TaskQueueDescription]
// WARNING: Worker versioning is currently experimental, and requires server 1.24+
DescribeTaskQueueEnhanced(ctx context.Context, options *DescribeTaskQueueEnhancedOptions) (TaskQueueDescription, error)
Copy link
Contributor

Choose a reason for hiding this comment

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

I know the old new version took pointers for options, I think @cretz prefers it without pointers. The SDK is not consistent here, but we should try to be consistent for new APIs. I think without a pointer is probably nicer since we don't have to deal withnil.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Happy to change that, I saw 50/50 of APIs using pointers, and the old versioning always using it.
But if we do change it, we should also change the new UpdateWorkerVersioningRules and GetWorkerVersioningRules to not have pointers, so that all are consistent...
@cretz what do you think?

Copy link
Member

Choose a reason for hiding this comment

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

👍 Confirmed on Slack, without pointers is best IMO

@antlai-temporal antlai-temporal marked this pull request as ready for review June 6, 2024 16:39
Copy link
Member

@cretz cretz left a comment

Choose a reason for hiding this comment

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

LGTM, only a couple of minor comments

client/client.go Outdated
// PollerInfo provides information about a worker/client polling a task queue.
// It is used by [Client.TaskQueueTypeInfo].
// WARNING: Worker versioning is currently experimental.
PollerInfo = internal.PollerInfo
Copy link
Member

Choose a reason for hiding this comment

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

Can this be called TaskQueuePollerInfo or WorkerPollerInfo or something? I think PollerInfo is a bit too generic for this big package.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

TaskQueuePollerInfo sounds great

client/client.go Outdated
// (index 0). If the given index is too larger the rule will be
// inserted at the end of the list.
// WARNING: Worker versioning is currently experimental
VersioningOpInsertAssignmentRule = internal.VersioningOpInsertAssignmentRule
Copy link
Member

Choose a reason for hiding this comment

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

I have no strong opinion. Operation works for me. I do appreciate how we're prefixing all of these w/ the same prefix though.

// - Backlog info for Workflow and/or Activity tasks
// When not supported by the server, it returns an empty [TaskQueueDescription]
// WARNING: Worker versioning is currently experimental, and requires server 1.24+
DescribeTaskQueueEnhanced(ctx context.Context, options *DescribeTaskQueueEnhancedOptions) (TaskQueueDescription, error)
Copy link
Member

Choose a reason for hiding this comment

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

👍 Confirmed on Slack, without pointers is best IMO

// - Backlog info for Workflow and/or Activity tasks
//
// WARNING: Worker versioning is currently experimental, and requires server 1.24+
func (wc *WorkflowClient) DescribeTaskQueueEnhanced(ctx context.Context, options *DescribeTaskQueueEnhancedOptions) (TaskQueueDescription, error) {
Copy link
Member

Choose a reason for hiding this comment

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

It is a bit confusing to have half of versioning client code in this file and half in another, but I understand why. There is an argument to be made for a VersioningClient() similar to our ScheduleClient(), but I'm ok w/ this since it's only 3 methods. No need to change anything, just thinking out loud.

Copy link
Member

Choose a reason for hiding this comment

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

I think all of this should go in internal_versioning_client.go instead of a new file, but not a super-strong opinion

@antlai-temporal antlai-temporal merged commit c73a007 into master Jun 7, 2024
14 checks passed
@antlai-temporal antlai-temporal deleted the versioning-2 branch June 7, 2024 08:27
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.

4 participants