Proto commits in temporalio/api

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2026-06-23

Worker Callbacks prototype

2026-06-22

Update doc strings for Worker Deployment (#811) **What changed?** Update doc strings for Worker Deployment **Why?** These got misplaced during an earlier commit rebase: https://github.com/temporalio/api/pull/810

The documentation is generated from this commit.

Add compute provider validation to worker deployment version summary (#810) **What changed?** Added `ComputeStatus` to the Worker Deployment API with a `ProviderValidationStatus` that tracks the result of the most recent connectivity check between Temporal and a customer's compute resource. An empty error message means validation passed; a non-empty message describes what failed. **Why?** Enables surfacing the connectivity health between Temporal and a customer's compute resource (e.g. Lambda) through the Worker Deployment API, so the UI can show ongoing validations status of compute configs without additional queries. **Breaking changes** None. All additions are new optional fields; existing clients are unaffected. **Server PR** https://github.com/temporalio/temporal/pull/10778

Update with more comprehensive info

2026-06-21

Suppress linter for one-time override field

2026-06-19

Add Nexus caller-identity types for principal propagation Aligns the public API with the Nexus caller identity propagation blueprint: - common.v1.Principal gains a stable `id` field (display name vs stable id). - common.v1.CallerRole enum + Caller{role, principal} message. - repeated Caller callers on WorkflowExecutionInfo, ActivityExecutionInfo, NexusOperationExecutionInfo, and PollNexusTaskQueueResponse. - removes the superseded NexusCallerInfo and root_caller_principal. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-18

Add runtime type information to worker heartbeats

add fields to list and describe

simplified scope

add reason

first draft

2026-06-17

Clarify one-time override completion semantics

Clarify one-time override routing comment

Rename one-time versioning override type

Add one-time versioning override API

Remove fields from ActivityExecutionListInfo

Workflow Task Completion Pagination API

rm ts from patch schedulers

change comments

move time skipping config from workflow folder to the common folder

add time skipping for saa

adding ts to schedulers

add TimeSkippingStatePropagation

refactor time skipping config and event

2026-06-16

Add requested_start_time and actual_start_time to activity execution info

Merge branch 'main' into dt-4089-cloud-run-capability

Add start_delay to ActivityOptions for update support

2026-06-15

[breaking-change] time skipping fast forward (#786) **What changed?** 1. Removed obsolete fields — safe to delete as this feature has not been released (disable compatibility checking temporarily) 2. Renamed `bound` to `fast forward` to define the concept from the perspective of users' behavior 3. Add `disable_propagation_for_child` to give users a way to stop propagation 4. Add `update_time` to `UpdateWorkflowExecutionOptionsRequest` 5. Moving TimeSkippingConfig from workflow path to common path **Why?** 1. for 1) make the API cleaner 2. for 2) a neat name to reduce misunderstanding 3. for 3) a child workflow is a different execution and has its own virtual clock, and users may need an option to change the default propagation behavior 4. for 4) this can be used when SDK verify the time in `TimeSkippingTransitionedEvent` match the sleep duration 5. for 5) other executions like schedulers will also use the config **Breaking changes** 1. removed the feature `maxSkippedDuration`-> the server has already implemented this feature need to delete the code first 2. restructured the `maxElapsedDuration`to `fast_forward`-> the server need to do renaming **Server PR** https://github.com/temporalio/temporal/pull/10576 --------- Co-authored-by: Spencer Judge <spencer@temporal.io> Co-authored-by: Spencer Judge <sjudge@hey.com>

Add poller_autoscaling_auto_enroll namespace capability (#803) ## What Add a new `poller_autoscaling_auto_enroll` boolean field to `NamespaceInfo.Capabilities`. ## Why Today, poller autoscaling requires explicit SDK-side opt-in via worker options. This capability lets the server tell SDKs to automatically enroll workers in poller autoscaling for specific namespaces, controlled by a namespace-scoped dynamic config — no user code changes needed. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

2026-06-12

Add some other necessary details to the CompletionRequest

Add nexus request variant for completion

Add WIP routing invocation information in poll response

2026-06-11

Add server_scaled_provider_cloud_run capability Advertises support for the Cloud Run compute provider for server-scaled deployments, so UIs can gate the provider option on server support.

Update comment on run_id, link and outcome based on review

2026-06-10

Add CountWorkers API (#729) ## What Add `CountWorkers` RPC to `WorkflowService` for counting workers matching a query filter. - Request: `namespace` + `query` + `include_system_workers` (same filter fields as `ListWorkers`) - Response: `int64 count` - HTTP route: `GET /namespaces/{namespace}/worker-count` [Server PR](https://github.com/temporalio/temporal/pull/9476) ## Why The worker UI needs to display a total worker count (e.g. in tabs) without fetching the full list. Follows the established pattern used by `CountWorkflowExecutions`, `CountSchedules`, and `CountActivityExecutions`. ## How did you test it? - [x] built (`make ci-build`) - [x] passes buf linting and breaking change checks - [x] regenerated OpenAPI specs --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

Add child workflow versioning override API

Add StartNexusOperationExecutionRequest.completion_callbacks

2026-06-08

Add Event Groups (#793)

Rename flag based on feedback to be more explicit.

2026-06-05

add start_delay to ActivityExecutionInfo (#797) **What changed?** Added a start_delay field to ActivityExecutionInfo **Why?** DescribeActivityExecutionResponse had no way to show the configured start delay back to callers. Putting it on ActivityExecutionInfo keeps it alongside the other configured values and makes it explicit to callers what it was set to during start or update.

2026-06-03

merge conflicts

Add include_heartbeat_details and include_last_failure to DescribeActivityExecutionRequest (#792) <!-- Describe what has changed in this PR --> **What changed?** Added `include_heartbeat_details` and `include_last_failure` to `DescribeActivityExecutionRequest`. The intention is that by default, `ActivityExecutionInfo` will omit `heartbeat_details` and `last_failure`. <!-- Tell your future self why have you made these changes --> **Why?** `heartbeat_details` and `last_failure` are user-controlled payloads and potentially very large. These changes allow sending these payloads only when specifically requested, reducing message size when they aren't needed. <!-- Are there any breaking changes on binary or code level? --> **Breaking changes** This PR changes what the default behavior of `DescribeActivityExecution` should be. The old behavior is equivalent to setting both `include_heartbeat_details` and `include_last_failure` to true. The server does not need to be immediately updated since the current implementation is functional with new API - however, once server implements the new API, old clients will break if they rely on the old behavior. Note that SAA APIs are in Public Preview and breaking changes can happen. <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> **Server PR** TBD

2026-06-01

more locations

add to command

feat: add PausePolicy to StartActivityExecutionRequest

Add generic optional fields to MarkerRecordedEventAttributes for LA use.

2026-05-31

Add api_next draft proto source

2026-05-28

Adds state_size_bytes to operation execution info (#791) **What changed?** Adds state_size_bytes to NexusOperationExecutionInfo **Why?** Enables storage estimates for operations

Merge branch 'master' into ks/ACT-919-activity-outcome

Update comment based on review

Add poller group info to DescribeNamespace (#788) <!-- Describe what has changed in this PR --> **What changed?** Add poller group info to `DescribeNamespace`. <!-- Tell your future self why have you made these changes --> **Why?** This allows SDK to send initial polls to the right poler groups and not have to wait for the first poll response up to 1 min. <!-- Are there any breaking changes on binary or code level? --> **Breaking changes** None <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> **Server PR**

2026-05-27

migrate workflownexusservice -> applicationservice

Add external payload transfer stats for workflow tasks

2026-05-26

get latest changes

delete max elasped duration

Merge branch 'master' into ks/ACT-919-activity-outcome

Update comment based on review Co-authored-by: Fred Tzeng <41805201+fretz12@users.noreply.github.com>

2026-05-22

renamings

rename

fixing docstrings

add sdk name and version to ActivityExecutionInfo (#782) **What changed?** Added two new fields to ActivityExecutionInfo in temporal/api/activity/v1/message.proto: - sdk_name (field 35) — name of the SDK of the worker that most recently picked up an attempt of the activity - sdk_version (field 36) — corresponding SDK version **Why?** Standalone Activities have no way to expose which SDK ran a given attempt. Workflows already expose this info; this PR adds the public API surface so DescribeActivityExecution can return the same info.

2026-05-21

Prototype activity completion improvements

2026-05-20

create a new service for async ops

Add state_size_bytes to ScheduleInfo, ScheduleListInfo (#780) **What changed?** - Added `state_size_bytes` to scheduler structs **Why?** - Needed by metering validation pipelines, potentially useful to customers interested in storage costs - Same pattern as in SAA **Breaking changes** - New fields only

Add optional activity outcome in start activity response

2026-05-19

Add Callbacks and Links to Workflow Update (#742) _**READ BEFORE MERGING:** All PRs require approval by both Server AND SDK teams before merging! This is why the number of required approvals is "2" and not "1"--two reviewers from the same team is NOT sufficient. If your PR is not approved by someone in BOTH teams, it may be summarily reverted._ <!-- Describe what has changed in this PR --> **What changed?** Add Callbacks and Links to Workflow Update. <!-- Tell your future self why have you made these changes --> **Why?** Will allow starting async updates from a Nexus Operation Handler <!-- Are there any breaking changes on binary or code level? --> **Breaking changes** <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> **Server PR** https://github.com/temporalio/temporal/pull/9614 --------- Co-authored-by: long-nt-tran <long.tran@temporal.io>

2026-05-18

Add errordetails.NexusOperationNotStartedFailure

2026-05-15

fixing lost changes

generate proto

diffs

use oneof and add Links

2026-05-14

Update temporal/api/callback/v1/message.proto Co-authored-by: Roey Berman <roey@temporal.io>

2026-05-13

Address PR feedback

Update comment

Add missing DescribeCallbackExecutionResponse.input field

Add Stand Alone Callbacks (rebase)

2026-05-12

Add "exposed" operation for system nexus endpoint (#736) **What changed?** Add `nexusannotations/v1` package to define service operations as exposed for Nexus handlers. A sample of a code generator that takes use of this command is [here](https://github.com/temporalio/api-go/commit/da6df036bed0ca1b4932ee9583214ac43c489c9c) **Why?** Enables the system nexus endpoint work in server repo **Breaking changes** NA **Server PR** NA

specify hosting provider

feat: add worker runtime info to heartbeat

2026-05-11

Add standalone Nexus operations namespace capability (#779) ## What changed? Add `standalone_nexus_operations` to `NamespaceInfo.Capabilities`. ## Why? Allows `DescribeNamespace` callers to determine whether standalone Nexus operations are available for a namespace.

2026-04-30

Add option to exclude system workers in ListWorkers API (#777) ## What Add `bool include_system_workers` field to `ListWorkersRequest` proto. When true, the response includes system workers that are not created by the user. By default, system workers are excluded. ## Why System workers (per-namespace workers for scheduler, batcher, etc.) show up in ListWorkers results, which is confusing for users who only care about their own workers. ## How did you test it? Build 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

2026-04-28

Add namespace soft deletion restoration API to operator handler

feat: Unified activity operator APIs (#743) **What changed?** Add `{Pause/Unpause/Reset/Update}ActivityExecution` RPCs and corresponding request/response pairs that will target both workflow embedded and standalone activities. These all strictly target a single activity by ID, if a workflow_id is specified on the request the operation targets a workflow activity. **Why?** Unified support for activity operations. **Breaking changes** None **Server PR** Does not break server

Add weak consistency option to DescribeNamespaceRequest (#775) <!-- Describe what has changed in this PR --> **What changed?** Added weak_consistency boolean field to `DescribeNamespaceRequest`. When set to `true`, the server may serve the response from an eventually-consistent source (e.g. the in-memory namespace registry) instead of reading through to persistence. <!-- Tell your future self why have you made these changes --> **Why?** `DescribeNamespace` currently always reads through to the persistence store. The new field lets clients opt into eventually-consistent reads where read-after-write semantics aren't required, while preserving the existing strong-consistency contract for operator/admin callers (default behavior unchanged). <!-- Are there any breaking changes on binary or code level? --> **Breaking changes** None. Additive field with default `false`, preserving current behavior for clients that don't set it. <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> **Server PR** https://github.com/temporalio/temporal/pull/10103

Specify resourceID for TriggerWorkflowRule (#768) <!-- Describe what has changed in this PR --> **What changed?** - Specify resourceID for TriggerWorkflowRule api <!-- Tell your future self why have you made these changes --> **Why?** - Specify resourceID for TriggerWorkflowRule api <!-- Are there any breaking changes on binary or code level? --> **Breaking changes** <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> **Server PR**

2026-04-27

Add worker_commands namespace capability (#771) ## What Add `worker_commands` bool field to capabilities. ## Why This feature requires SDK to implicitly create a new task queue and poller per process. Preferable to do this in a controlled manner. ## How did you test it? Build 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

2026-04-25

Experimental API example

2026-04-24

Add ExternalStorageReference proto (#772)

api changes for time-skipping propagation (#770) **What changed and why?** Propagation refers to how time-skipping config is carried over to all workflows started by the current workflow: retry, continue-as-new, child workflows, reset, etc. 1. Remove **disable_propagation** and **max_target_time**, because neither of them can be soundly defined when time-skipping propagates transitively across related workflows. One of the many examples: - max_target_time: as an absolute time point, it may already have passed by the time a retry or downstream workflow starts, making it ambiguous whether to disable or preserve time-skipping — neither is a clearly correct default - disable_propagation: it is unclear which type of transitively triggered workflow this should apply to, and treating all cases uniformly is unreasonable; we defer exposing this flexibility until user demand and use cases are better understood 2. Add **comments of the propagation behavior** for each feature (retry, continue-as-new, child workflow, reset, cron) 3. Add **comments to the bound field** 4. Add **propagatedSkippedDuration** to time skipping config so that new workflows can inherit the virtual time ** Breaking changes to API ** 1. deleted fields and reused the numbers since the TimeSkippingConfig is not yet released

Add start delay field to StartActivityExecutionRequest (#767) **What changed?** Added a start_delay field to StartActivityExecutionRequest in the proto definition and updated the OpenAPI specs accordingly. **Why?** To allow callers to specify a delay before the first standalone activity task is dispatched, matching the existing start delay capability available for workflow-started activities.

2026-04-23

Standalone Nexus Operations (#685) **What changed?** - Added the full API scope for standalone nexus operations. **Server PR** https://github.com/temporalio/temporal/pull/9869 --------- Co-authored-by: Stephan Behnke <stephanos@users.noreply.github.com>

2026-04-22

Feat/heartbeat count (#769) <!-- Describe what has changed in this PR --> **What changed?** This adds a field for counting the total number of heartbeats given to an activity, as received by the server (as an aside, this may be less than the client activity.RecordHeartbeat() calls due to the client's throttling of this call. For this change, I'm just commandeering the work already done by @fretz12. <!-- Tell your future self why have you made these changes --> **Why?** This is to provide this information about the total number of heartbeats in the DescribeActivity API call / CLi invocation. <!-- Are there any breaking changes on binary or code level? --> **Breaking changes** Should be backwards compatible. <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> **Server PR** Should be backwards compatible. Co-authored-by: Fred Tzeng <fred.tzeng@temporal.io>

2026-04-21

Merge remote-tracking branch 'origin/master' into standalone-nexus-op # Conflicts: # openapi/openapiv2.json

Add revision_number to DeclinedTargetVersionUpgrade (#762) <!-- Describe what has changed in this PR --> - Added `revision_number` to `DeclinedTargetVersionUpgrade`, which already took in a deployment version. - Recap about what `DeclinedTargetVersionUpgrade` does: the main intention of this field was to "remember" which target version we have rejected when a pinned workflow declines to AU when CAN'ing. However, you could have matching partitions send you back stale target deployment versions, and we don't want to "bounce back" and CAN our pinned workflows when they see such a stale version. For that very purpose, we resort to now store the revision number here. <!-- Tell your future self why have you made these changes --> - I explained it above <!-- Are there any breaking changes on binary or code level? --> - None, changes are additive. - Also, no changes required from the SDK perspective <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> https://github.com/temporalio/temporal/pull/9895 Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Add Poller Group fields (#744) - **Add poller groups** - **rename resource_id to routing key for nexus** - **fix typo** - **Add poller group fields** <!-- Describe what has changed in this PR --> **What changed?** Adding `poller-group-id` and `poller-group-info` fields to the poll APIs. <!-- Tell your future self why have you made these changes --> **Why?** SDK needs to pass poller group ID in some APIs according to server instructions. <!-- Are there any breaking changes on binary or code level? --> **Breaking changes** None <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> **Server PR** No new API added.

add timeouts

2026-04-15

Add workspace and sandbox proto definitions - WorkspaceAccessMode enum (READ_WRITE, READ_ONLY) - WorkspaceTransferMode enum (HANDOFF, FORK) - WorkspaceInfo, WorkspaceCommit, WorkspaceTransfer, DiffRecord messages - ActivityWorkspaceOptions with disk_limit_mb on ScheduleActivityTaskCommandAttributes - SandboxOptions, SandboxResourceLimits, SandboxNetworkPolicy messages - workspace_info on ActivityTaskScheduledEventAttributes - workspace_commit on ActivityTaskCompletedEventAttributes - workspace_transfers on StartChildWorkflowExecutionCommandAttributes

add on conflict options for standalone activities (#764) **What changed?** Added a new OnConflictOptions message to temporal.api.activity.v1 and a corresponding on_conflict_options field to StartActivityExecutionRequest. **Why?** When StartActivityExecution uses ACTIVITY_ID_CONFLICT_POLICY_USE_EXISTING and a matching activity is already running, the caller needs a way to specify what should be attached to the existing activity (request ID, completion callbacks, links). This mirrors the existing OnConflictOptions for workflows (temporal.api.workflow.v1.OnConflictOptions on StartWorkflowExecutionRequest) but is specific to the activity domain.

2026-04-14

Add link field to propagate backlink in signal and signal-with-start responses (#761) <!-- Describe what has changed in this PR --> **What changed?** Added `link` fields on `SignalWorkflowExecutionResponse` and `SignalWithStartWorkflowExecutionRequest`. I think a singular link should suffice but if reviewers feel otherwise (especially w.r.t. `SignalWithStartWorkflowExecutionRequest`) let me know. <!-- Tell your future self why have you made these changes --> **Why?** To propagate backlinks on signal and signal-with-start executions back to the caller. <!-- Are there any breaking changes on binary or code level? --> **Breaking changes** Not a breaking change (unused field) <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> **Server PR** https://github.com/temporalio/temporal/pull/9897

add time-skipping config in WorkflowExecutionStartedEventAttributes (#758) **What changed?** add time-skipping config (optional field) in WorkflowExecutionStartedEventAttributes **Why?** there won't be a way to show it to users and support workflow rebuilt