-
Notifications
You must be signed in to change notification settings - Fork 220
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
Conversation
* add new VersioningIntent options * BuildId -> BuildID * address comments
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 |
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.
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
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.
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?
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.
I have no strong opinion. Operation
works for me. I do appreciate how we're prefixing all of these w/ the same prefix though.
internal/client.go
Outdated
// - 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) |
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.
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
.
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.
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?
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.
👍 Confirmed on Slack, without pointers is best IMO
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.
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 |
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.
Can this be called TaskQueuePollerInfo
or WorkerPollerInfo
or something? I think PollerInfo
is a bit too generic for this big package.
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.
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 |
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.
I have no strong opinion. Operation
works for me. I do appreciate how we're prefixing all of these w/ the same prefix though.
internal/client.go
Outdated
// - 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) |
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.
👍 Confirmed on Slack, without pointers is best IMO
internal/internal_workflow_client.go
Outdated
// - 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) { |
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.
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.
internal/worker_versioning_rules.go
Outdated
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.
I think all of this should go in internal_versioning_client.go
instead of a new file, but not a super-strong opinion
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
Support the new versioning API #1420