Add Create and Update for Worker Deployment Version, update scaler config and enable per-task-type compute providers by 02strich · Pull Request #731 · temporalio/api

02strich · 2026-03-18T06:38:13Z

What changed?

Enables validating, creating and updating compute providers at the worker deployment version level, as that is where it at the most basic belongs
Making the scaler config more flexible to allow for pluggable scalers
Allowing for different compute providers depending on task types and regions

temporal/api/compute/v1/config.proto

temporal/api/workflowservice/v1/request_response.proto

semgrep-managed-scans · 2026-03-18T23:21:42Z

Semgrep found 1 missing-explicit-permissions finding:

.github/workflows/trigger-api-go-update.yml
- L17-64 - Triage

No explicit GITHUB_TOKEN permissions found at the workflow or job level. Add a permissions: block at the workflow root (applies to all jobs) or per job with least privilege (e.g., contents: read and only specific writes like pull-requests: write if needed).

temporal/api/compute/v1/config.proto

temporal/api/compute/v1/scaler.proto

temporal/api/workflowservice/v1/request_response.proto

temporal/api/compute/v1/config.proto

temporal/api/workflowservice/v1/request_response.proto

Adding a Create API for Worker Deployment Versions, as well as a compute config setting at the version level as that is the matching one. A Deployment Version references a specific running version of a worker, which is also what a compute provider tracks.

Both scaler and compute providers are pluggable, so aligning the formats for easier understanding.

Advanced customers might want to define different compute providers for different task types, so enabling splitting that up.

jaypipes · 2026-03-20T12:42:16Z

temporal/api/workflowservice/v1/request_response.proto

+    // Optional. Contains the compute config scaling groups to remove from the Worker Deployment.
+    repeated string remove_compute_config_scaling_groups = 7;


I'm not a huge fan of separating out a "remove" list from an "add/update" list, but if this is a pattern used elsewhere in the API, ok :) I prefer a Replace-style pattern where the user passes the exact desired state, including any existing list or map fields and the server simply replaces those fields with the supplied values. Additionally, having a add or remove separate API call to add/remove individual list items from a list field is a good idea. So, in this case, we'd add AddWorkerDeploymentVersionScalingGroup and RemoveWorkerDeploymentVersionScalingGroup API calls...

But again, if this is not a pattern used in the existing API, so be it :)

Yeah, this was changed from replace-style to add/update based on feedback what is used elsewhere in the API

jaypipes · 2026-03-20T12:43:27Z

temporal/api/workflowservice/v1/request_response.proto

+    string namespace = 1;
+
+    // Required.
+    string deployment_name = 2;


How is the build ID/version of the WDV identified in this request message?

There is no build ID/version yet when running this validate API as it is not used in validation

Hmm. Seems odd to have WorkerDeploymentVersion in the API name, then... Maybe better to go with ValidateComputeConfig?

Yeah, I had been unhappy with that contradiction as well. That said ValidateComputeConfig seems too generic as well which is why I didn't go with it.

I now reframed it a bit: added in the build ID as well. This way the story is more that the validate-compute-config should mirror the update-compute-config more than the create version API. That means it clearly should have the build ID. Down the road this might also be useful once we can validate that the compute reference points at the configured build ID.

jaypipes

👍

temporal/api/compute/v1/config.proto

temporal/api/compute/v1/provider.proto

bergundy · 2026-03-20T22:56:20Z

temporal/api/compute/v1/provider.proto

-        // will be an encrypted, encoded bytestring containing
-        // provider-specific information. The implementation must understand
-        // how to decrypt the payload.
+        // Encrypted, encoded bytestring containing provider-specific 


This would be optionally encrypted.

temporal/api/compute/v1/scaler.proto

bergundy · 2026-03-20T22:58:53Z

temporal/api/workflowservice/v1/request_response.proto

+
+    // Optional. Contains the compute config scaling groups to add or updated for the Worker
+    // Deployment.
+    map<string, temporal.api.compute.v1.ComputeConfig.ScalingGroup> compute_config_scaling_groups = 6;


I would recommend using field masks for update APIs. We've done that in a few places (see UpdateActivityOptions). This way if you add fields that the client is not aware of they will not accidentally be deleted on update.

@ShahabT ?

This was what other APIs around here already used.

temporal/api/compute/v1/provider.proto

temporal/api/compute/v1/scaler.proto

temporal/api/workflowservice/v1/request_response.proto

bergundy · 2026-03-23T19:13:09Z

temporal/api/workflowservice/v1/request_response.proto

+    repeated string remove_compute_config_scaling_groups = 7;
+
+    // Optional. Controls which fields from `compute_config_scaling_groups` will be applied
+    google.protobuf.FieldMask update_mask = 8;


It would be a separate field per ComputeConfigScalingGroup though, no?

the field mask could express the map, no? I could make it per entry but that seems somewhat redundant with what the field mask can already do (if I just make it a map<string, FieldMask>).

I would do either map<string, FieldMask> here or map<string, ComputeConfigScalingGroupUpdate> where ComputeConfigScalingGroupUpdate is a message that has both a ComputeConfigScalingGroup and a FieldMask. I prefer the latter.

bergundy · 2026-03-23T19:14:08Z

temporal/api/workflowservice/v1/request_response.proto

+    // This value is returned so that it can be optionally passed to APIs
+    // that write to the Worker Deployment state to ensure that the state
+    // did not change between this API call and a future write.
+    bytes conflict_token = 5;


I'm also wondering whether the conflict token is even needed here since there's two types of operations:

Update specific fields

Remove a group

Both are idempotent on their own and do not rely on a previous state.

Unless I'm misunderstanding how you expect the updates to be submitted. Partial updates (patches) would be easier to use for users typically and save the need to handle conflicts.

I think conflicts can still occur, just the scope is more specific so I would argue the pattern of conflict tokens would hold even with partial updates (though would agree they are less critical)

AFAIC, conflict token can be optional for sensitive updates where there's a risk but just deleting a group or updating a field on a group doesn't require it IMHO.

bergundy

LGTM, but I would double check that the implementation that backs this works before merging into main.

temporal/api/workflowservice/v1/request_response.proto

02strich force-pushed the stefan/serverless-v2 branch 2 times, most recently from 4b74a6b to 448fcaa Compare March 18, 2026 15:47

02strich force-pushed the serverless branch from 21376f0 to 18e3e3f Compare March 18, 2026 15:51

02strich force-pushed the stefan/serverless-v2 branch 4 times, most recently from 86892e0 to 7ca9f8b Compare March 18, 2026 21:35

ShahabT reviewed Mar 18, 2026

View reviewed changes

temporal/api/compute/v1/config.proto Outdated Show resolved Hide resolved

temporal/api/workflowservice/v1/request_response.proto Outdated Show resolved Hide resolved

temporal/api/workflowservice/v1/request_response.proto Outdated Show resolved Hide resolved

02strich force-pushed the stefan/serverless-v2 branch 2 times, most recently from 42cbcff to 7ce67c6 Compare March 18, 2026 23:17

02strich force-pushed the stefan/serverless-v2 branch from 7ce67c6 to 041a11a Compare March 18, 2026 23:27

bergundy reviewed Mar 18, 2026

View reviewed changes

02strich force-pushed the stefan/serverless-v2 branch from 041a11a to 49d52e9 Compare March 19, 2026 00:36

02strich requested review from ShahabT and bergundy March 19, 2026 00:46

ShahabT reviewed Mar 19, 2026

View reviewed changes

temporal/api/workflowservice/v1/request_response.proto Outdated Show resolved Hide resolved

ShahabT reviewed Mar 19, 2026

View reviewed changes

temporal/api/compute/v1/config.proto Outdated Show resolved Hide resolved

ShahabT reviewed Mar 19, 2026

View reviewed changes

temporal/api/compute/v1/config.proto Outdated Show resolved Hide resolved

ShahabT reviewed Mar 19, 2026

View reviewed changes

temporal/api/workflowservice/v1/request_response.proto Outdated Show resolved Hide resolved

02strich force-pushed the stefan/serverless-v2 branch 2 times, most recently from 11be549 to ae4546c Compare March 19, 2026 20:17

02strich requested a review from ShahabT March 19, 2026 21:15

02strich force-pushed the stefan/serverless-v2 branch from ae4546c to 309b565 Compare March 19, 2026 23:13

02strich marked this pull request as ready for review March 19, 2026 23:14

02strich requested review from a team as code owners March 19, 2026 23:14

02strich added 3 commits March 19, 2026 16:15

Align scaler config with compute provider one

343b775

Both scaler and compute providers are pluggable, so aligning the formats for easier understanding.

Enable splitting compute providers by different task types

bffb53b

Advanced customers might want to define different compute providers for different task types, so enabling splitting that up.

02strich force-pushed the stefan/serverless-v2 branch 2 times, most recently from a3cbeea to 387d6ad Compare March 19, 2026 23:24

jaypipes reviewed Mar 20, 2026

View reviewed changes

02strich force-pushed the stefan/serverless-v2 branch from 387d6ad to a19c407 Compare March 20, 2026 17:04

jaypipes approved these changes Mar 20, 2026

View reviewed changes

bergundy reviewed Mar 20, 2026

View reviewed changes

02strich force-pushed the stefan/serverless-v2 branch from a19c407 to 5aa7da9 Compare March 23, 2026 16:18

bergundy reviewed Mar 23, 2026

View reviewed changes

temporal/api/compute/v1/provider.proto Outdated Show resolved Hide resolved

temporal/api/compute/v1/scaler.proto Outdated Show resolved Hide resolved

temporal/api/workflowservice/v1/request_response.proto Outdated Show resolved Hide resolved

02strich force-pushed the stefan/serverless-v2 branch 2 times, most recently from 9c10378 to a25db8a Compare March 23, 2026 17:44

bergundy reviewed Mar 23, 2026

View reviewed changes

02strich force-pushed the stefan/serverless-v2 branch from a25db8a to 4d33b58 Compare March 23, 2026 19:49

bergundy approved these changes Mar 23, 2026

View reviewed changes

temporal/api/workflowservice/v1/request_response.proto Outdated Show resolved Hide resolved

Address PR feedback

06629f5

02strich force-pushed the stefan/serverless-v2 branch from 4d33b58 to 06629f5 Compare March 23, 2026 19:58

02strich merged commit 06713e4 into serverless Mar 23, 2026
3 checks passed

02strich deleted the stefan/serverless-v2 branch March 23, 2026 20:01

		// Optional. Contains the compute config scaling groups to remove from the Worker Deployment.
		repeated string remove_compute_config_scaling_groups = 7;

Conversation

02strich commented Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

semgrep-managed-scans bot commented Mar 18, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

jaypipes left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

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!

bergundy left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

02strich commented Mar 18, 2026 •

edited

Loading