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).

bergundy · 2026-03-18T23:34:41Z

temporal/api/compute/v1/config.proto

-    // Informs a worker lifecycle controller *when* and *how often* to perform
-    // certain worker lifecycle actions like starting a serverless worker.
-    temporal.api.compute.v1.ComputeScaler scaler = 2;
+    message ComputeConfigScalingGroup {


nit: not need to qualify this as ComputeConfig... if it's embedded inside a ComputeConfig message.
That being said, if you think there's any chance that this message would need to be used outside of this context, I would make it top level.

Removed the prefix

bergundy · 2026-03-18T23:36:33Z

temporal/api/compute/v1/config.proto

+
+        // The region of the temporal server for which this compute config should apply.
+        // This is used together with replication to enable clean-hand-off when migrating regions.
+        optional string region = 4;


nit: why is region field number 4 if it's the second field defined here?

no special reason, re-numbered

bergundy · 2026-03-18T23:38:51Z

temporal/api/compute/v1/scaler.proto

+    // type of the compute scaler. this string is implementation-specific and
+    // can be used by implementations to understand how to interpret the
+    // contents of the scaler_details field.
+    string type = 1;


nit: use upper case letters when starting sentences to be consistent with the rest of the API.

bergundy · 2026-03-18T23:39:40Z

temporal/api/compute/v1/scaler.proto

+
+    // Contains scaler-specific instructions and configuration.
+    oneof detail {
+        // will be an unencrypted, JSON-encoded object of scaler-specific


nit: "will be" doesn't quite sound right here, i wouldn't use the future tense.

bergundy · 2026-03-18T23:40:18Z

temporal/api/compute/v1/scaler.proto

+        // (-- api-linter: core::0146::any=disabled
+        //     aip.dev/not-precedent: This needs to be extensible to
+        //     externally-written compute scalers --)
+        string detail_json = 2;


Why not use payload always? Payload with metdata["encoding"] = "json/plain" achieves what you want here.

The detail_json is consumed by the server (i.e. parsed and understood), while the payload is meant to be used with remote providers and passed onward as-is without the server inspecting it.

If even with that context, you believe this should always be a payload, happy to change it (this was specific feedback we had received on the first API PR).

bergundy · 2026-03-18T23:41:45Z

temporal/api/workflowservice/v1/request_response.proto

+    repeated temporal.api.compute.v1.ComputeConfig.ComputeConfigScalingGroup remove_compute_config_scaling_groups = 5;
+
+    // Optional. The identity of the client who initiated this request.
+    string identity = 4;


nit: make this field number 2 because it's mostly metadata and common across different requests.

bergundy · 2026-03-18T23:45:13Z

temporal/api/workflowservice/v1/request_response.proto

+    // Required.
+    string deployment_name = 2;
+
+    // Optional. Contains the new worker compute configuration for the Worker


What happens if this is empty? Shouldn't it be "required"?

thanks, copy&paste mistake. Text updated

bergundy · 2026-03-18T23:45:38Z

temporal/api/workflowservice/v1/request_response.proto

+    string identity = 4;
+}
+
+message UpdateWorkerDeploymentVersionComputeConfigResponse {


Do we need to return a conflict token here?

bergundy · 2026-03-18T23:47:55Z

temporal/api/workflowservice/v1/request_response.proto

 }

+// Used to update the compute config of a Worker Deployment Version.
+message UpdateWorkerDeploymentVersionComputeConfigRequest {


Shouldn't this take a conflict token and a ComputeConfig object?

What about a request ID?

done - both

bergundy · 2026-03-18T23:48:19Z

temporal/api/workflowservice/v1/request_response.proto

+
+    // Optional. The identity of the client who initiated this request.
+    string identity = 4;
+    // A unique identifier for this create request for idempotence. Typically UUIDv4.


Worth noting how this is used, does the server dedupe requests with the same idempotency key?

@ShahabT can you confirm the details so I am not mis-representing here?

here is the behavior, we can document:

Retrying with same request id is a successful no-op.

Retrying with different request id is an error.

One the object is deleted, any request id (even one used for a previous creation) will re-create it.

Updated the comment with Shahab's notes

ShahabT · 2026-03-19T16:31:46Z

temporal/api/workflowservice/v1/request_response.proto

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


@02strich what do you expect the server do for this API? also, related, does deployment name play any role in the validation? if not, should we remove it?

Only in the sense that a deployment should be present. I think having it can come in beneficial if we decide to go for default values in the deployment or similar approaches down the road. Given that these are mapped to HTTP paths, adding it later won't be super straightforward.

ShahabT · 2026-03-19T16:39:45Z

temporal/api/compute/v1/config.proto


+        // The region of the temporal server for which this compute config should apply.
+        // This is used together with replication to enable clean-hand-off when migrating regions.
+        optional string region = 2;


let's remove optional for consistency and instead clarify in the comment that it is optional. Specify want would be the behavior for a replicated NS if this value is not provided. Can one have a scaling group with region set and another scaling group without region, say as a catch-all?

Also, if the implementation is not going to be ready in the first release, we should not merge it yet.

Overall, I'm not sure if we should add the region dimension just yet. It's definitely not needed for the MVP and I worry we're complicating things by adding a premature dimension.

Made consistent using the "Optional." in the comment instead of the protobuf label. And updated the comment to be clear that it is a catch all if not provided.

I am aiming for this being supported in the first release as MRN is a really interesting use case.

removed it for now until we can settle on the name

ShahabT · 2026-03-19T16:42:07Z

temporal/api/compute/v1/config.proto

-    message ComputeConfigEntry {
+    message ScalingGroup {
        // The set of task queue types this compute config serves.
        repeated temporal.api.enums.v1.TaskQueueType task_queue_types = 1;


Would empty list be supported? if so, would it mean a catch-all?
Also clarify that same region cannot have more than one scaling group for the same tq type.

yes empty would be supported and catch-all - updated the text

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

👍

bergundy · 2026-03-20T22:55:15Z

temporal/api/compute/v1/config.proto

-    // Informs a worker lifecycle controller *when* and *how often* to perform
-    // certain worker lifecycle actions like starting a serverless worker.
-    temporal.api.compute.v1.ComputeScaler scaler = 2;
+    message ScalingGroup {


nit: I would flatten this out to a top level message if there's any chance that this message will be reused in the future.

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

temporal/api/compute/v1/provider.proto

-        // how to decrypt the payload.
+        // Encrypted, encoded bytestring containing provider-specific 
+        // information. The implementation must understand how to decrypt the payload.
        temporal.api.common.v1.Payload detail_payload = 3;


Use only payload please, there's a straightforward way of expressing plain JSON in a payload.

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.

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

temporal/api/compute/v1/scaler.proto

+        string detail_json = 2;
+
+        // Encrypted, encoded bytestring containing scaler-specific 
+        // information. The implementation must understand how to decrypt the payload.
+        temporal.api.common.v1.Payload detail_payload = 3;


Same here, no need for both of these fields.

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.

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

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

Address PR feedback

a19c407

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

		// 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!

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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

02strich commented Mar 18, 2026 •

edited

Loading