Merge serverless into master by ShahabT · Pull Request #752 · temporalio/api

ShahabT · 2026-04-01T23:13:28Z

This PR merges the serverless branch into master.

Server PR to be sent shortly.

feature: introduce compute config Introduces a new `compute.v1` package of proto messages that house the various instructions and information needed by worker control plane controllers `temporal.api.compute.v1.ComputeConfig` has three fields, `task_queues`, `provider` and `scaler` that store the configuration information for the server-owned worker setup and how the worker control plane should treat worker lifecycle events (such as when no pollers exist for a task queue that has received a task). The `temporal.api.compute.v1.ComputeConfig.task_queues` field is a list of task queue name and task type tuples. When Temporal Server receives a task with any of these name+type combinations and finds no active pollers, it will trigger a launch of a server-owned Worker using the configuration information in the `provider` field. The `temporal.api.compute.v1.ComputeConfig.provider` field is of type `temporal.api.compute.v1.ComputeProvider`. This message is a simple wrapper around a blob of bytes that contains configuration settings for a worker control plane controller. The configuration settings for the worker control plane controller are specific to different compute providers. The first compute provider we are modeling is AWS Lambda, and the `ProviderDetailAWSLambda` message houses the ARN of the AWS Lambda Function to be invoked and an optional ARN of the IAM Role that should be assumed by a worker control plane controller when invoking the function. The `temporal.api.compute.v1.ComputeConfig.scaler` field is of type `temporal.api.compute.v1.ComputeScaler`. This message contains instructions for when the worker lifecycle controller should scale up or down the number of workers in a WorkerDeployment or WorkerDeploymentVersion. Adds a new field `compute_config` to `WorkerDeploymentInfo` and `WorkerDeploymentVersionInfo` that contains a `temporal.api.compute.v1.ComputeConfig` message. Both WorkerDeployment and WorkerDeploymentVersion have this field in order to handle versioned workers properly. For example, if the user wants to use PINNED temporal versioning, they will be creating a WorkerDeploymentVersion that is specific to, say, a qualified Lambda Function ARN. Therefore we need to place compute provider configuration on a WorkerDeploymentVersion in addition to WorkerDeployment. Adds three new gRPC API methods to WorkflowService: * `CreateWorkerDeployment` creates a new WorkerDeployment containing the supplied compute configuration. * `UpdateWorkerDeploymentComputeConfig` updates an existing WorkerDeployment's compute configuration. * `UpdateWorkerDeploymentComputeConfig` updates an existing WorkerDeploymentVersion's compute configuration. Signed-off-by: Jay Pipes <jay.pipes@temporal.io> Signed-off-by: Jay Pipes <jay.pipes@temporal.io>

* origin/master: Add Principal to the base HistoryEvent (#733)

…nfig and enable per-task-type compute providers (#731) **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

…gRequest

ShahabT · 2026-04-01T23:16:20Z

.github/workflows/trigger-api-go-update.yml


          gh workflow run update-proto.yml -R https://github.com/temporalio/api-go \
-            -r master \
+            -r "${BRANCH}" \


This causes the api-go's update-proto.yml be loaded from the branch on which we trigger the update, not from master all the time.

ShahabT · 2026-04-01T23:44:29Z

Makefile


 PROTO_ROOT := .
-PROTO_FILES = $(shell find temporal -name "*.proto")
+PROTO_FILES = $(shell find temporal -name "*.proto" -not -name "*.swp")


@jaypipes what this change do? should we merge it to master?

@ShahabT heh, this was for those of us who use Vi(m)... when Vim has a file open, it creates a .swp file, and the make generate Make target was picking up those temporary files.

I highly recommend using set dir^=~/.local/tmp// in vimrc to keep swap files outside of source dirs. We shouldn't have to clutter our code to exclude editor temp files for all different editors.

I highly recommend using set dir^=~/.local/tmp// in vimrc to keep swap files outside of source dirs. We shouldn't have to clutter our code to exclude editor temp files for all different editors.

ack. even though there's already VSCode and Emacs stuff in .gitignore.

@ShahabT heh, this was for those of us who use Vi(m)... when Vim has a file open, it creates a .swp file, and the make generate Make target was picking up those temporary files.

as mentioned to @ShahabT earlier today in slack, feel free to remove this change.

semgrep-managed-scans · 2026-04-02T00:16:04Z

Semgrep found 1 missing-explicit-permissions finding:

.github/workflows/trigger-api-go-update.yml
- L16-63 - 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).

rkannan82 · 2026-04-03T00:19:57Z

temporal/api/common/v1/message.proto

    string name = 1;
 }

-// Uniquely identifies a combination of task queue name and type.


Why is this reverted?

we didn't endup using it.

Sushisource

Nothing blocking but some comment fixes that should definitely be applied &/or added

temporal/api/compute/v1/scaler.proto

Sushisource · 2026-04-03T17:34:28Z

temporal/api/compute/v1/scaler.proto

+    // converter to ensure the server can understand it.
+    // For remote-implemented scalers, you might use your own content
+    // converters according to what the remote endpoints understand.
+    temporal.api.common.v1.Payload details = 2;


IMO It would make sense for this field to be a oneof with our built-in providers as well-defined messages.

Makes sense to me but this is how we built it for now. I guess we could make it a oneof after private-preview if we want. cc @02strich @jaypipes

@Sushisource that's what my original proposal had but I was asked to make it a Payload.

ref: 2319887

Sushisource · 2026-04-03T17:36:23Z

temporal/api/workflowservice/v1/request_response.proto

+        // True if the server supports server-scaled deployments.
+        // This flag is dependent both on server version and for server-scaled deployments
+        // to be enabled via server configuration.
+        bool server_scaled_deployments = 12;


Who's this meant to be read by? If it's useful for SDK, this should go in namespace capabilities since that's what we call on startup. At least for what I've done so far, I don't need this, so maybe that's fine, but the principle applies to clients generally.

This is added for UI.

temporal/api/workflowservice/v1/request_response.proto

Sushisource · 2026-04-03T17:41:18Z

temporal/api/workflowservice/v1/request_response.proto

+    map<string, temporal.api.compute.v1.ComputeConfigScalingGroupUpdate> compute_config_scaling_groups = 6;
+
+    // Optional. Contains the compute config scaling groups to remove from the Worker Deployment.
+    repeated string remove_compute_config_scaling_groups = 7;


What're the semantics if the same string is used in both add and remove?

@02strich to clarify the behavior. (I guess delete will take effect)

Yes delete wins

Plz add to docstrings

Co-authored-by: Spencer Judge <sjudge@hey.com>

jaypipes and others added 16 commits March 18, 2026 08:50

Cleanup WD compute config initial protos

d73e535

Auto-update api-go based on serverless branch

e9a0371

Fix compile

1864315

Fix trigger-api-go-update.yml to work on non-master branches

128d99e

comment change

18e3e3f

Add serverless_deployments capability flag

2c8564b

Merge remote-tracking branch 'origin/master' into serverless

da7c338

* origin/master: Add Principal to the base HistoryEvent (#733)

Remove conflict token from CreateWorkerDeploymentVersion

983d345

add a missing deprecation mark for version_info.deployment_name

1f5c61d

add WORKER_DEPLOYMENT_VERSION_STATUS_CREATED

8354024

Merge remote-tracking branch 'origin/master' into serverless

6fce99a

Add last_modifier_identity for WDV

26bafd7

Support partial update in ValidateWorkerDeploymentVersionComputeConfi…

ac3371e

…gRequest

cleanup for merging to master

b5cd975

ShahabT requested review from a team April 1, 2026 23:13

ShahabT commented Apr 1, 2026

View reviewed changes

02strich approved these changes Apr 1, 2026

View reviewed changes

ShahabT commented Apr 1, 2026

View reviewed changes

ShahabT enabled auto-merge (squash) April 3, 2026 00:05

rkannan82 reviewed Apr 3, 2026

View reviewed changes

rkannan82 approved these changes Apr 3, 2026

View reviewed changes

revert Makefile

0552413

Sushisource approved these changes Apr 3, 2026

View reviewed changes

ShahabT and others added 3 commits April 3, 2026 12:06

Apply suggestions from code review

2dbbfaf

Co-authored-by: Spencer Judge <sjudge@hey.com>

Merge remote-tracking branch 'origin/master' into serverless

1b22f04

generate openapi

eb3550f

ShahabT merged commit 52ec420 into master Apr 3, 2026
3 checks passed

ShahabT deleted the serverless branch April 3, 2026 19:09

Conversation

ShahabT commented Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

semgrep-managed-scans bot commented Apr 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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

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!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

ShahabT commented Apr 1, 2026 •

edited

Loading