Register task-queue workers through worker deployment #7380
Conversation
| @@ -580,7 +581,7 @@ func (c *physicalTaskQueueManagerImpl) ensureRegisteredInDeploymentVersion( | |||
| ctx, namespaceEntry, workerDeployment.SeriesName, workerDeployment.BuildId, c.queue.TaskQueueFamily().Name(), c.queue.TaskType(), | |||
| "matching service", uuid.New()) | |||
| if err != nil { | |||
| var errTooMany deployment.ErrMaxTaskQueuesInDeployment | |||
| var errTooMany workerdeployment.ErrMaxTaskQueuesInDeployment | |||
There was a problem hiding this comment.
this seems to be an error and is something I directly worked on :(
Sorry! Caught it now and verified things are working by running the test TestDeploymentVersionLimits and having a peek at it's output.
| TaskQueueType: taskQueue.Type, // since request doesn't pass through frontend, this field is not automatically populated | ||
| // Since request doesn't pass through frontend, this field is not automatically populated. | ||
| // Moreover, DescribeTaskQueueEnhanced requires this field to be set to WORKFLOW type. | ||
| TaskQueueType: enumspb.TASK_QUEUE_TYPE_WORKFLOW, |
There was a problem hiding this comment.
this might be an error on my end - if for example, the missing task-queue was an activity type, sending an activity type in this field will result in the Describe call returning an error : Describe cannot be called on an activity type - in this example, to fetch activity task-queue's stats, you pass the type in the types field (which I am doing
| @@ -407,6 +490,27 @@ func (d *WorkflowRunner) validateDeleteVersion(args *deploymentspb.DeleteVersion | |||
| return d.validateStateBeforeAcceptingDeleteVersion(args) | |||
| } | |||
|
|
|||
| func (d *WorkflowRunner) deleteVersion(ctx workflow.Context, args *deploymentspb.DeleteVersionArgs) error { | |||
There was a problem hiding this comment.
consolidated the main logic of deleting a version into a helper because when an individual delete version request were to come in, we need to acquire the lock vs tryDelete requests spurring up when registering a worker cannot acquire a lock since the workflow, at that point in time, is already holding on to it
PS - Since consolidating into a helper won't necessarily change the execution path of old currently-running worker-deployment workflows, this change won't require patching.
What changed?
Why?
How did you test it?
Potential risks
Documentation
Is hotfix candidate?