Add CreateWorkerDeployment API by ShahabT · Pull Request #9380 · temporalio/temporal

ShahabT · 2026-02-22T19:06:09Z

Point go.temporal.io/api to serverless branch of api-go
Add CreateWorkerDeployment API

What changed?

New API added for explicitly creating a worker deployment. also supports passing Compute Config

Why?

Needed for serverless workers.

How did you test it?

Potential risks

None

# Conflicts: # go.sum

jaypipes · 2026-02-23T17:59:06Z

proto/internal/temporal/server/api/deployment/v1/message.proto

    // Used to track which propagations are still pending across continue-as-new.
    map<string, PropagatingRevisions> propagating_revisions = 8;
+    // Request ID used to create this worker deployment.
+    string create_request_id = 9;


I presume you will be using the lack of a create_request_id to differentiate between WorkerDeployments that were not created with the CreateWorkerDeployment API call -- and thus were lazily created?

there'd be still a request ID but with special prefix.

jaypipes · 2026-02-23T18:01:14Z

service/frontend/configs/quotas.go

 		"/temporal.api.workflowservice.v1.WorkflowService/UpdateWorkerBuildIdCompatibility": 2,
 		"/temporal.api.workflowservice.v1.WorkflowService/UpdateWorkerVersioningRules":      2,
+
+		// Anything that changes task queue user data also creates replication tasks.


what are "replication tasks"?

tasks that are generated by our replication stack to copy things from one cluster to another one for MRN namespaces.

removed from this PR

jaypipes · 2026-02-23T18:14:13Z

service/worker/workerdeployment/client.go

 	if allowNoPollers {
-		// we want to start the Worker Deployment workflow if it hasn't been started by a poller
+		if b := versionObj.GetBuildId(); b != "" {
+			// Empty build id is accepted for unset.


What do you mean by "accepted for unset"?

unset current or ramping version.

jaypipes · 2026-02-23T18:20:20Z

service/worker/workerdeployment/client.go

+
+	updateRequest := &updatepb.Request{
+		Input: &updatepb.Input{Name: CreateWorkerDeployment, Args: updateArgs},
+		Meta:  &updatepb.Meta{UpdateId: "_create_" + requestID, Identity: identity},


might be good to create a const for "create" like you did for the AutoCreate one...

this is just used once and is only the WorkflowUpdate's request ID, not gonna be used as the create_request_id inside the workflow state. The reason I add the prefix is to differentiate the request id for create vs other APIs such as setcurrent etc. in case user sends the same request ID we still treat them differently. Adding this as a comment in the code.

jaypipes · 2026-02-23T18:38:49Z

service/worker/workerdeployment/client.go

+		Meta:  &updatepb.Meta{UpdateId: "_create_" + requestID, Identity: identity},
+	}
+
+	outcome, err := updateWorkflowWithStart(


I mentioned this on one of Stefan's PRs as well, but I personally find the name updateWorkflowWithStart() to be incredibly confusing. Apparently this doesn't update a workflow at all but uses the rather weirdly-named WorkflowUpdate operation... updateWorkflowWithStart should really have been called WaitForWorkflowStatus...

From what I read, UpdateWorkflowWithStart means: start workflow if it doesn't exist, and then send an update to it.

jaypipes · 2026-02-23T18:42:53Z

service/worker/workerdeployment/version_workflow_test.go

-	t.Run("v1", func(t *testing.T) {
-		suite.Run(t, &VersionWorkflowSuite{workflowVersion: AsyncSetCurrentAndRamping})
-	})


any reason to remove this?

this mode is not supported in prod anymore so no need for testing it.

jaypipes · 2026-02-23T18:45:52Z

service/worker/workerdeployment/workflow.go

 }

+func (d *WorkflowRunner) validateCreateWorkerDeployment(args *deploymentspb.CreateWorkerDeploymentArgs) error {
+	// Only valid if deployment is deleted or the request ID matches the current one.


sorry, explain to me why the CreateWorkerDeploymentArgs is valid if the WorkflowRunner's deleteDeployment flag is true?

this was to cover an edge case where we admit a delete and create simultaneously but we process create after the delete. thinking more, in that case, it's ok for create to return "already existed" error. simplifying this part.

jaypipes · 2026-02-23T18:50:19Z

service/worker/workerdeployment/workflow.go

+	if err := d.validateDeleteDeployment(); err != nil {
+		return err
+	}


Is this unrelated to the addition of CreateWorkerDeployment?

yes, I noticed the check does did not exist before. We should have it.

removing it from this PR

rkannan82 · 2026-02-25T03:46:53Z

proto/internal/temporal/server/api/deployment/v1/message.proto

+// used as Worker Deployment workflow update input:
+message CreateWorkerDeploymentArgs {
+    string identity = 1;
+    string request_id = 2;


Please document the semantics of this request id is. It seems like:

Retrying with same request id is a no-op.

With different request id is an error.

Unless the deployment is deleted, in this case it is revived.

Added. Here is the semantics:

// Retrying with same request id is a successful no-op. // Retrying with different request id is an error. // One deployment is deleted, same or different request id will re-create it.

rkannan82 · 2026-02-25T03:47:57Z

proto/internal/temporal/server/api/deployment/v1/message.proto

    bytes conflict_token = 2;
 }

+// used as Worker Deployment workflow update input:


Reword: Used as the input to the worker deployment workflow.

rkannan82 · 2026-02-25T03:54:40Z

proto/internal/temporal/server/api/deployment/v1/message.proto

    // Used to track which propagations are still pending across continue-as-new.
    map<string, PropagatingRevisions> propagating_revisions = 8;
+    // Request ID used to create this worker deployment.
+    string create_request_id = 9;


Drop prefix create?

I think I slightly prefer the prefix because this is a long-lived entity receiving many types of requests after creation.

rkannan82 · 2026-02-25T03:55:26Z

service/worker/workerdeployment/client.go

 	return dInfo, queryResponse.GetState().GetConflictToken(), nil
 }

+func (d *ClientImpl) queryCreateRequestID(


nit: Just queryRequestId. Also update the error text.

rkannan82 · 2026-02-25T04:40:43Z

service/worker/workerdeployment/client.go

+	requestID string,
+) ([]byte, error) {
+	// Check if deployment already exists and whether it was created by this request.
+	res, err := d.queryCreateRequestID(ctx, namespaceEntry, deploymentName)


Is this an optimization to fail fast? Asking since even if it succeeds here, it is possible that it will fail on the server due to a race. Right?

yes, this is an optimization, the race condition is handled by updatewithstart. the reason for the optimization is that we don't want to send updates to the workflow needlessly because it generates history events (ideally, we should right nothing in case of duplicate request ID.)

rkannan82 · 2026-02-26T03:20:59Z

service/worker/workerdeployment/client.go

+
+	conflictToken, err := d.ensureWorkerDeploymentDoesNotExist(ctx, namespaceEntry, deploymentName, requestID)
+	if err != nil {
+		// WD already exists, or other errors


with different request id?

rkannan82 · 2026-02-26T03:29:00Z

service/worker/workerdeployment/client.go

+		Meta:  &updatepb.Meta{UpdateId: "_create_" + requestID, Identity: identity},
+	}
+
+	outcome, err := updateWorkflowWithStart(


From what I read, UpdateWorkflowWithStart means: start workflow if it doesn't exist, and then send an update to it.

rkannan82 · 2026-02-26T04:02:05Z

service/worker/workerdeployment/workflow.go

+func (d *WorkflowRunner) revive(ctx workflow.Context, args *deploymentspb.CreateWorkerDeploymentArgs) error {
+	// Reset routing config to clear all previous timestamps still present from previous life.
+	routingConfig := &deploymentpb.RoutingConfig{
+		// We preserve the revision number in case of a previous delete while there were propagating revisions.


I didn't understand this comment. Can you describe in terms of what happens if we didn't do this and instead just did d.State.Reset?

I got rid of the revive function, it was overly complicated.

rkannan82

General comments.

This PR packs a lot of changes. Suggest adding some details to the PR description --- call out key changes like files and what was changed. This helps reviewers who are not very familiar with the codebase.
In the future, please see if it makes sense to split into multiple PRs. While we need to review all of them to get the full picture, I have found it easier to review and identify problems/regressions if the PRs are small and focused.
Example:

Proto/API
Server side: Handler code
Frontend: client code

This PR merges the serverless feature branch into main. Individual PRs included in this branch: - #9380 - #9651 - #9412 - #9746 - #9759 --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Stefan Richter <stefan.richter@temporal.io>

Add CreateWorkerDeployment API

364e542

ShahabT requested review from a team as code owners February 22, 2026 19:06

ShahabT added 5 commits February 22, 2026 14:10

Change implementation to workflow update

add0a2b

Merge remote-tracking branch 'origin/serverless' into create-wd

0a277ed

# Conflicts: # go.sum

Add unit tests

85b5353

Fix functional tests

e97de4a

add the new api name in all the 1000 places

3afbe45

jaypipes reviewed Feb 23, 2026

View reviewed changes

rkannan82 reviewed Feb 26, 2026

View reviewed changes

rkannan82 approved these changes Feb 26, 2026

View reviewed changes

ShahabT added 2 commits March 11, 2026 10:03

address comments

ec82191

fix tests

e9ccf57

ShahabT merged commit a95db75 into serverless Mar 11, 2026
41 checks passed

ShahabT deleted the create-wd branch March 11, 2026 17:27

ShahabT mentioned this pull request Apr 2, 2026

Serverless Feature Integration #9779

Merged

Conversation

ShahabT commented Feb 22, 2026

What changed?

Why?

How did you test it?

Potential risks

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rkannan82 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

rkannan82 left a comment •

edited

Loading