## What changed
`RPCFactory` and the SDK client factory close the gRPC connections they
own on shutdown, as fx stop hooks. Removes the four gRPC connection
ignores from the leak test.
Also bumps `auto-scaled-workers` to pick up
temporalio/temporal-auto-scaled-workers#108, without which the SDK
connection stays open.
## Why?
Nothing released these connections, so every connection's goroutines and
the membership resolver watching for changes outlived the cluster.
Clients from `NewClient` share the system client's ref-counted
connection, so the SDK closes it only once the last one is closed.
## How did you test it?
- [x] built
- [x] covered by existing tests
`make leak-test` at the CI settings reports `no unexpected goroutines`.
Each change was verified to fail the leak test when reverted.
## What changed?
Bump `go.temporal.io/api` from the pseudo-version
`v1.63.5-0.20260804201935-e54fd69950e1` to the tagged release `v1.63.5`,
in both the root module and `tests/mixedbrain`.
## Why?
Cloud releases may only ship tagged versions of `go.temporal.io/api`.
The v1.63.5 tag points at `e54fd699`, the same api-go commit the
pseudo-version already referenced, so no api code changes are included.
## How did you test it?
- [x] covered by existing tests
## What changed?
- Do not reset heartbeats by default
- Honor `reset_heartbeat` flag
## Why?
- Parity with WFA
- This product behavior makes sense: a user with a long-running activity
using exponential backoff on attempt 10 may wish to reset the attempt
counter in order that the next retry backoff is short, and yet preserve
their checkpointed progress.
## How did you test it?
- [x] modified existing functional test(s)
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Changes activity reset semantics and persisted state for heartbeat
checkpoints across immediate and deferred reset paths; behavior is
well-covered by tests but affects long-running activity retry/reset
workflows.
>
> **Overview**
> Activity reset now **rewinds the attempt counter** but **keeps
persisted heartbeat checkpoint details by default**, matching
workflow-activity behavior. Clearing heartbeats is **opt-in** via
`reset_heartbeat` / `ResetHeartbeat` on reset APIs.
>
> CHASM activity state adds `reset_should_clear_heartbeat` for resets
requested while a worker is still running; clearing runs when the
attempt yields (same deferred pattern as `restore_original_options`).
Immediate reset paths (`reset`, `resetKeepPaused`) and
cancel-on-reset-request clear that deferred flag only when the flag is
set.
>
> Standalone activity reset forwarding no longer forces `ResetHeartbeat:
true`; it passes the client request. Model/events add
`ResetClearingHeartbeat`; parity and functional tests cover keep vs
clear for scheduled and started activities.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
09fb7a0bd1. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
## What changed?
Update sqlparser to v0.1.0. It's actually no-op since it points to the
same commit.
## Why?
Use tagged version instead of commit.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
## What changed?
Added a missing `d.syncSummary()` call in
`syncVersionDataToComputeStatus`, so it now notifies the parent
Deployment workflow after pulling a compute status from WCI.
## Why?
Without this, the pull only updates the Version workflow's own state.
The Deployment workflow (which
`ListWorkerDeployments`/`DescribeWorkerDeployment` actually read from)
is not updated, so `computeStatus` can stay permanently missing from the
API even when the data is available.
## How did you test it?
- [x] built
- [x] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
See API change https://github.com/temporalio/api/pull/846
## What changed?
- Drop `reset_attempts` and `reset_heartbeat` from
`UnpauseActivityExecution`
## Why?
- We have so far been unable to assign desirable and consistent
semantics to them during implementation: for example if
`Unpause[resetAttempts]` is received during retry backoff it is unclear
whether to honor the remaining delay time, because this is how Unpause
usually behaves, or dispatch immediately, because this is how Reset
behaves.
- No known user demand
- They are confusing: they mix `Unpause` and `Reset` functionality in a
confusing way
- They can be added later
## How did you test it?
- [x] covered by existing tests
## Breaking changes
- This API has always been rejected by the server. When server starts to
accept it, an old client could submit these options and they would be
ignored. Operator API is not GA.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Changes activity unpause scheduling semantics for the execution API
and drops reset-on-unpause behavior that was only partially implemented;
low user impact if the API was not GA and had no known callers.
>
> **Overview**
> Aligns the server with the **UnpauseActivityExecution** API change:
**`reset_attempts`** and **`reset_heartbeat`** are no longer part of
unpause for standalone (CHASM) activities.
>
> **CHASM activity unpause** no longer resets attempt count, retry
interval, or heartbeat state on unpause, and always considers the
pending retry backoff when scheduling dispatch (the branch that skipped
that when `reset_attempts` was set is removed). Workflow-embedded
unpause forwarding via **`UnpauseActivityExecution`** no longer passes
those fields to the legacy **`UnpauseActivity`** history call (jitter
and identity only).
>
> **`go.temporal.io/api`** is bumped to the revision that removes the
fields from **`UnpauseActivityExecutionRequest`**.
>
> **Tests** are updated so unpause helpers no longer take a reset flag;
reset-on-unpause coverage stays on legacy **`UnpauseActivity`** only
(execution API skips that case). Standalone tests for
**`UnpauseWithResetAttempts`** and **`UnpauseWithResetHeartbeat`** on
**`UnpauseActivityExecution`** are removed.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
7a41d507ca. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
## What changed?
Exposed RetryState on standalone activity execution outcomes and
persisted it in activity state. Retry evaluation now records terminal
reasons including retry policy not set, cancellation requested,
non-retryable failure, maximum attempts reached, and timeout.
## Why?
Standalone activities previously collapsed retry decisions into a
boolean, preventing callers from distinguishing why an activity stopped
retrying. This brings standalone activity behavior and observability
into parity with workflow activities.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [X] covered by existing tests
- [X] added new unit test(s)
- [X] added new functional test(s)
## Potential risks
During a rolling upgrade, activities closed by an older server may
return RETRY_STATE_UNSPECIFIED. Existing closed activities also remain
unspecified because retry state was not previously persisted. Older
clients safely ignore the new protobuf field.
---------
Co-authored-by: Dan Davison <dandavison7@gmail.com>
## What changed?
Added request-ID-based idempotency for standalone activity unpause,
reset, and update-options operations. Successful request IDs are
persisted in activity state and duplicate requests are handled as
no-ops.
## Why?
These APIs can be retried after timeouts or transient failures.
Persisting the latest successful request ID prevents duplicate
mutations, including delayed unpause retries undoing a later pause.
Workflow-backed activity support will follow separately.
## How did you test it?
- [X] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [X] added new unit test(s)
- [X] added new functional test(s)
---------
Co-authored-by: Dan Davison <dandavison7@gmail.com>
## What changed?
1. add a max skip field to TimeSkippingConfig
2. add TimeSkippingInfo to DescribeWorkflowExecution (contains virtual
current time and running status)
3. add PollWorkflowExecutionTimeSkipping for fast-forward completion
## Why?
1. a generic mechanism to stop endless retries or schedules
2. to give clients easier access to time skipping state changes
related API change: https://github.com/temporalio/api/pull/835
## What changed?
Bump `github.com/temporalio/ringpop-go` to `v0.1.0` and
`github.com/temporalio/tchannel-go` to `v1.22.1`, replacing the previous
commit pseudo-versions.
Picks up ringpop-go#22 (bounds label and member resource usage on
incoming membership changes, fixes a state-transition timer leak) and
tchannel-go#14 (returns errors instead of panicking on malformed call
frames).
## Why?
Pull the membership/transport robustness fixes from both forks into the
server. Both forks are now tagged, so we can pin real releases instead
of commit hashes.
## How did you test it?
- [x] built
- [x] covered by existing tests
## What changed?
Upgrade SDK to v1.44.0.
## Why?
Keep up with SDK releases.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
## What changed?
Update to API v1.53.4.
## Why?
Keep up with API releases.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
## What changed?
Added `history.enableStandaloneActivityOperatorCommands`, defaulting to
false. The flag gates Reset, Pause, Unpause, and Update Activity
Execution Options only for standalone activities. Workflow activity
commands are unaffected.
## Why?
Allow standalone activity operator commands to be rolled out explicitly
while preserving existing workflow activity behavior.
## How did you test it?
- [x] covered by existing tests
- [x] added new unit test(s)
## Potential risks
NA, these have not been turned on yet.
## What changed?
Update sqlparser dependency to latest version
## Why?
Update sqlparser dependency to latest version
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
## What changed?
Update sqlparser dependency to latest commit
## Why?
Include latest changes in the sqlparser.
## How did you test it?
- [x] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
## What changed?
- terminate, cancel, delete standalone activity batch operations
- Add OperationType to ListBatchOperations
- Show query/executions and operation type on DescribeBatchOperation
## Why?
Terminate, cancel, delete are available batch operations for workflows,
providing them for standalone activities brings SAA up to parity.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [X] covered by existing tests
- [X] added new unit test(s)
- [X] added new functional test(s)
## Potential risks
Changes to batch operations introduces the risk of non-backwards
compatible code. This code has been manually (human-read) audited for
backwards compatability.
---------
Co-authored-by: ks-temporal <281732484+ks-temporal@users.noreply.github.com>
## What changed?
- Added the standalone activity start delay namespace capability to
DescribeNamespace.
- The capability is enabled only when both standalone activities and
start delay are enabled.
- Enabled standalone activity start delay by default.
- Updated the API dependency and namespace capability tests.
## Why?
Clients need to determine whether standalone activity start delay is
available for a namespace before using it. Start delay is enabled by
default for GA
## How did you test it?
- [X] built
- [ ] run locally and tested manually
- [X] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed
- Adds server support for explicit child workflow versioning overrides.
- Records the child override on StartChildWorkflowExecutionInitiated
history events.
- Validates malformed override shape before recording the initiated
event where possible.
- Records INVALID_VERSIONING_OVERRIDE if child start later fails because
the pinned version is no longer in the child task queue.
- Keeps inherited pinned and AutoUpgrade behavior when no explicit child
override is provided.
## Coverage
- VersioningOverride structural validation.
- StartChildWorkflowExecutionInitiated event records the normalized
child override.
- Transfer task child-start success path preserves existing behavior.
- Transfer task invalid versioning override path records
StartChildWorkflowExecutionFailed.
- Functional pinned child override takes precedence over parent routing.
- Functional AutoUpgrade child override takes precedence over parent
pinned routing.
- Functional invalid pinned child override records the new failed cause.
- Functional malformed pinned child override fails the parent workflow
task before the initiated event is written.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Changes worker-versioning routing and validation on child starts and
history events; mistakes could mis-route children or change failure
semantics, but behavior is heavily tested and scoped behind explicit
overrides.
>
> **Overview**
> Adds **explicit `VersioningOverride` on Start Child Workflow** so
callers can pin, one-time route, or auto-upgrade a child independently
of parent versioning.
>
> **Validation and errors:** `ValidateVersioningOverrideStructure`
splits shape checks from matching/reactivation logic; malformed
overrides fail the parent workflow task at completion, and the transfer
path records `StartChildWorkflowExecutionFailed` with
`INVALID_VERSIONING_OVERRIDE` for bad structure or when a pinned target
is not on the child task queue (`IsPinnedVersionNotInTaskQueueError`).
>
> **Routing:** When the child command carries an override, it **wins
over** inherited pinned version, override, build ID, and auto-upgrade
info; history records the **v0.32-normalized** override on
`StartChildWorkflowExecutionInitiated`. Without an explicit override,
existing inheritance behavior is unchanged.
>
> **Deps/tests:** Bumps `go.temporal.io/api`; adds unit,
transfer-executor, and functional versioning-3 coverage for precedence,
one-time, and failure paths.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
9c4c32fa2c. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
…fecycle events
Add common/events: a pluggable events.Handler for emitting structured
("wide") events, with a typed Encoder (incl. Any for whole-object
values), a global event registry (NewEventDef) with startup
duplicate-name validation, a default handler that logs each event as one
line keyed by the event type, and a noop handler. Wired through the
server via WithCustomEventHandler, catalog validation at bootstrap, a
per-service fx provider, and a GetEventHandler() accessor on
ShardContext.
Define two events on the framework:
- NamespaceLifecycle: a generic, phase-discriminated namespace event
(stable identity fields + a nested "details" object). Emitters supply
the phases.
- ReplicationLifecycle: traces a replication task sent -> executing ->
applied across sync_workflow_state / sync_versioned_transition /
verify_versioned_transition, emitted at the stream sender, the passive
executables, and the ndc workflow-state replicator (post-apply
mutable-state summary, no extra read).
## What changed?
^
## Why?
Improve lifecycle observability
## How did you test it?
- [x] built
- [x] run locally and tested manually
- [ ] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Stephan Behnke <stephanos@users.noreply.github.com>
## Summary
- replace the `go.temporal.io/api` pseudo-version with tagged release
`v1.63.3`
- refresh the corresponding `go.sum` entries
## Why
Cloud release dependencies must use tagged versions before the 3.159
release cut. The coordinated `temporalio/api` and `temporalio/api-go`
`v1.63.3` releases are published. `go.temporal.io/sdk` remains tagged at
`v1.41.1`.
## Validation
- `go mod verify`
- `make lint-code`
- tagged-dependency grep returns no API or SDK pseudo-version
## What changed?
Delete any pending workflow task when unpausing a workflow.
## Why?
Pausing a WF invalidates pending WFT by bumping the stamp, but leaves it
recorded as pending. Unpausing will force create a fresh workflow task
`api.UpdateEvent{CreateWorkflowTask: true}`, but this will not fire `if
!mutableState.HasPendingWorkflowTask()`.
I found this while investigating CI failures for
`TestScheduleCHASMWorkflowPauseInteraction/UnpauseRecovery/CancelOther`.
`CANCEL_OTHER` will issue a cancel request to the running WF around the
time it is paused, leaving a pending WFT at pause time. Unpausing hits
this bug, the workflow never closes and the schedule's completion
callback will not fire.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [X] covered by existing tests -
`TestAddWorkflowExecutionUnpausedEvent` updated to assert the fix.
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
Deleting the pending WFT could cause issues but the task was already
invalidated by the stamp bump.
## What changed?
Added benchstat utility as a tool for ease of access.
## Why?
Go benchmarks are fairly difficult to read in larger test runs,
and even more difficult across changes
and repeated samples.
The standard benchstat utility can be used to
simplify the output and explain comparisons in
statistically significant ways.
## How did you test it?
- [x] built
- [x] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
Added a time-windowed tdigest implementation to allow for local
collection of health-related statistics. These will be used to report on
system health via the DeepHealthCheck endpoints on the history and
frontend services.
## Why?
The existing moving averages are not sufficient to track cluster health
accurately. T-digest allows for the collection and measurement of
trimmed-mean and quantile measures.
## How did you test it?
- [x] built
- [x] run locally and tested manually
- [ ] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)
---
Note: Branched from https://github.com/temporalio/temporal/pull/9940
---------
Co-authored-by: Nick Beaumont <nicholas.beaumont@temporal.io>
## What changed?
the server changes for an api field rename
https://github.com/temporalio/api/pull/817
## How did you test it?
- [x] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [x] added new functional test(s)
## What
Populates the new `rate_limiting_active` field in `TaskQueueStats` so
auto-scaling systems can detect when backlog growth is caused by rate
limiting rather than insufficient worker capacity.
Records rate-limit events via a callback from
`matcherData.findAndWakeMatches` into a `taskTracker`. The field is true
when any dispatch was rate-limited in the last 30 seconds.
## Why
When a task queue has a whole-queue rate limit configured,
WorkerControllerInterface (WCI) `PullStats` path sees backlog and scales
up workers. More workers don't help — they poll but can't receive tasks
faster than the rate limit. This field lets WCI suppress scaling in that
case.
## How did you test it?
- Unit tests for sync match and backlog dispatch paths
(`TestSyncMatchRateLimitedIncrementsStats`,
`TestBacklogRateLimitedIncrementsStats`)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
## What changed?
Bumped pgx dependency to v5.10.0
## Why?
Fixes CWE-306
## How did you test it?
- [X] built
- [ ] run locally and tested manually
- [X] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
CI should point any regressions
## What changed?
While it had been in the API spec from early on, it was missing on the
WCI side and has now been added.
## Why?
Eventually we want to use Nexus as an extension point to allow custom
compute providers for Serverless, which will need the endpoint to work
correctly.
## How did you test it?
- [x] built
- [x] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Summary
- Add `VersioningOverride.one_time` support so operators can route
workflow tasks to a target Worker Deployment Version without creating a
sticky pinned override.
- While pending, one-time behaves like `PINNED / <target>` for effective
routing, visibility search attributes, `WorkerDeploymentName`,
validation, and reactivation.
- When a WFT successfully completes on the target version, history
records the worker-reported base behavior/version, logs the fulfillment,
emits `worker_deployment_versioning_one_time_override_count`, and clears
the override before recomputing effective state.
- Child workflows inherit a pending one-time override only when the
target version is valid for the child task queue. Continue-as-new,
retry, and cron do not inherit it as sticky state; the normal target-WFT
completion path clears it before those close commands are applied, and
stale started-WFT close commands with buffered option updates are
rejected.
- Reset/reapply keeps working through the existing
`WorkflowExecutionOptionsUpdated` event path.
- `UpdateWorkflowExecutionOptions` now treats v0.32 `versioningOverride`
oneof updates atomically while preserving the deprecated `behavior` +
`deployment` field-mask pair for compatibility.
## Tests
- `GOWORK=off go test -tags test_dep ./common/worker_versioning
-count=1`
- `GOWORK=off go test -tags test_dep
./service/history/api/updateworkflowoptions -count=1`
- `GOWORK=off go test -tags test_dep ./service/history/workflow -run
^TestMutableStateSuite$ -testify.m TestOneTimeOverride -count=1`
- `GOWORK=off go test -tags test_dep ./tests -run
TestVersioning3FunctionalSuite/TestOneTimeOverride -count=1`
- Mutation check: temporarily disabled the one-time clear line and
confirmed the clearing-dependent functional scenarios failed; restored
the line and reran the functional subset successfully.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Touches workflow versioning routing, effective state, and
close-command paths (CAN/child/reset); behavior is heavily tested but
mistakes could mis-route tasks or leave overrides uncleared.
>
> **Overview**
> Adds **`VersioningOverride.one_time`** so operators can route the next
workflow task to a target deployment version without leaving a permanent
pinned override. While pending, one-time overrides behave like
**pinned** for routing, effective deployment/behavior, search
attributes, validation, and version reactivation;
**`go.temporal.io/api`** is bumped for the new proto shape.
>
> **Fulfillment:** when a workflow task completes on the target version,
history keeps the worker-reported base state, clears the override, logs
fulfillment, and increments
**`worker_deployment_versioning_one_time_override_count`**.
>
> **API & updates:** v0.32 `versioningOverride` oneof updates via
`UpdateWorkflowExecutionOptions` must be atomic (nested field masks
rejected); legacy `behavior` + `deployment` masks stay supported.
>
> **Inheritance:** child workflows can inherit a pending one-time
override when the target is valid for the child task queue;
continue-as-new does not carry the override as sticky state (with a warn
if one appears during CAN). Shared helpers
**`GetOverrideTargetDeploymentVersion`** unify pinned and one-time paths
across history, transfer queue, and reactivation signaling.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
cba8f589ca. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
## What changed?
`DescribeWorkerDeployment` now returns compute status per version,
checking whether Temporal can successfully interact with the version's
compute resource. `ListWorkerDeployments` also returns compute status on
the current, ramping, and latest version summaries, fetched in parallel.
When connectivity changes (e.g. Lambda becomes unreachable or is
restored), WCI signals the version workflow, which propagates the update
to the deployment workflow memo. The list view reads from the memo —
versions that have been validated since deployment will show their
status immediately; others will appear once the first validation runs.
## Why?
Allows customers to see whether Temporal can successfully interact with
their compute resource directly from the Worker Deployments list and
detail views, without navigating into each individual version.
## How did you test it?
- [x] built
- [x] run locally and tested manually
- [ ] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)
## What changed and why
1) make server compatible to breaking api change
https://github.com/temporalio/api/pull/786
2) change the propagation policy of time skipping to
- for the same execution (a chain of runs) all time skipping state and
config are shared using StatePropagation
- for child executions
virtual time is always propagated to have causal time
but the fast forward action is never propagated
configuration propagation is controlled by a separate flag
3) rename bound to fast-forward
## How did you test it?
- [x] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [x] added new unit test(s)
- [x] added new functional test(s)
## Potential risks
the sequence of this pr
1. review this pr first 2. merge api 3. update this pr with public api
dependency and merge
## What
Add `CountWorkers` RPC to count workers matching a query filter without
retrieving full worker details.
## Why
The UI needs to display a worker count in places where listing isn't
necessary. A dedicated count API follows the existing pattern
(`CountWorkflowExecutions`, `CountSchedules`).
## How did you test it?
- [x] new unit tests: count all, count with query filter, count with no
matches, invalid query error
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
## What changed?
Bumps Go module dependencies and the Go toolchain to clear HIGH/CRITICAL
CVEs disclosed by the Go security team between May 22 and June 2, 2026:
- `golang.org/x/crypto` v0.50.0 → v0.52.0 (Critical: GO-2026-5005,
-5006, -5017, -5019, -5020, -5021, -5023; High: -5013, -5018; plus
Mediums)
- `golang.org/x/net` v0.53.0 → v0.55.0 (Critical: GO-2026-5026 idna;
plus Mediums)
- Go toolchain 1.26.3 → 1.26.4 (High: CVE-2026-42504, GO-2026-5038; plus
Mediums in net/textproto, crypto/x509, mime)
- `golang.org/x/sys` v0.43.0 → v0.45.0 (required by x/crypto v0.52.0 and
x/net v0.55.0; also clears Low GO-2026-5024)
- `golang.org/x/term` and `golang.org/x/text` bumped transitively
## Why?
Required prerequisite for the upcoming v1.31.1, v1.30.5, and v1.29.7 OSS
patch releases. grype scans on current main staging images are flagging
11 HIGH/CRITICAL findings against these specific deps; this PR clears
all of them.
## How did you test it?
- [X] built
- [ ] run locally and tested manually
- [X] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
Populate ActivityExecutionInfo.StartDelay in buildActivityExecutionInfo
so the configured start delay is echoed back by
DescribeActivityExecution.
## Why?
StartDelay was wired into the activity state but was missing from the
Describe response, leaving clients unable to observe the configured
delay after start.
## How did you test it?
- [X] built
- [ ] run locally and tested manually
- [X] covered by existing tests
- [ ] added new unit test(s)
- [X] added new functional test(s)
## What changed?
Bumped `modernc.org/sqlite` to v1.51.0 and removed the custom
`Driver`/`conn` wrapper in `sqlite/driver.go` that implemented
`ResetSession()` and `IsValid()`.
## Why?
The wrapper existed to stop `database/sql` from discarding the single
in-memory connection on a context-cancelled transaction (which lost the
whole database). v1.51.0 fixes this upstream — in-memory connections now
stay usable after interruption ([cznic/sqlite
c1d418e](c1d418e0de))
— so the workaround is redundant.
## How did you test it?
- [x] built
- [x] covered by existing tests
`TestSQLiteTransactionContextCancellation` (the in-memory cancellation
regression test) and the rest of the SQLite persistence suite pass.
## What changed?
Add StateSizeBytes to NexusOperationInfo set to ApproximateStateSize
## Why?
Enables storage estimations
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)
Bumps Go from 1.26.2 to 1.26.3 to resolve scanner findings for 4 Go
stdlib CVEs:
- **CVE-2026-42499** — `net/mail` `consumePhrase` quadratic complexity
- **CVE-2026-39820** — `net/mail` `consumeComment` quadratic complexity
- **CVE-2026-33811** — `net` `LookupCNAME` double-free with cgo resolver
- **CVE-2026-39836** — `net` `Dial`/`LookupPort` panic on NUL byte
(Windows-only)
None are practically exploitable against Temporal Server (no `net/mail`
usage, `CGO_ENABLED=0`, Linux containers), but the Go version in the
binary triggers customer vulnerability scanners.
Also bumps `github.com/apache/thrift` from 0.22.0 → 0.23.0 (ref #10202).
## What changed?
- Added `sdk_name`/`sdk_version` to `ActivityAttemptState and
`ActivityExecutionInfo` (via the companion api PR).
- Added `chasm.Context.RequestHeader(key) string` so transitions can
read inbound gRPC metadata directly.
- `TransitionStarted` stamps `client-name`/`client-version` onto the
attempt; `buildActivityExecutionInfo` expose them through
`DescribeActivityExecution`. Overwritten per attempt.
- Consolidated the scattered `TestDescribeActivityExecution_*` methods
into one parent with parallel subtests.
## Why?
Standalone Activities had no way to convey which SDK ran a given
activity. The SDK already sends `client-name`/`client-version` on every
poll and `headers.Propagate` carries them to history, so the only
missing piece was a way for the CHASM transition to read them.
`RequestHeader(key)` is intentionally narrow: gRPC metadata lives in the
Go context under an unexported key that `chasm.Context.Value()` can't
reach. A single-purpose accessor for inbound transport metadata captures
what we need without opening that door.
## How did you test it?
- [X] built
- [X] run locally and tested manually
- [X] covered by existing tests
- [X] added new unit test(s)
- [X] added new functional test(s)
## What changed?
Added support for Nexus workflow update completion callbacks via CHASM.
This allows a Nexus caller to be notified when a workflow update
completes by attaching completion callbacks to the update request.
## Why?
Nexus operations that target workflow updates need a way to receive
completion notifications. Without this, a Nexus caller that sends an
update has no async mechanism to learn when the update finishes.
Completion callbacks enable the same async notification pattern that
already exists for workflow-level Nexus operations.
## How did you test it?
- [ ] built
- [x] run locally and tested manually
- [ ] covered by existing tests
- [x] added new unit test(s)
- [x] added new functional test(s)
## Potential risks
Touches speculative workflow updates, they are always hard to reason
about. Tried to compensate with lots of test coverage.
Note: Needs this API PR
https://github.com/temporalio/api/pull/742/changes
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **High Risk**
> Touches workflow update state machine and mutable state event handling
to persist/trigger per-update callbacks, including close/retry/reset
paths, which is complex and can affect correctness of update outcomes
and callback delivery.
>
> **Overview**
> Adds **workflow update completion callbacks** via CHASM so Nexus
callers can register callbacks on `UpdateWorkflowExecution` and have
them fired on update completion or workflow close.
>
> This introduces a `WorkflowUpdate` CHASM component with new
`UpdateState` protobuf (including persisted `rejection_failure`), stores
update callbacks under `Workflow.Updates`, and extends callback
processing to handle *update-level* callbacks on update completion,
rejection (including reset/reapply), and on run transitions
(retry/timeout/continue-as-new) where update callbacks must fire even if
workflow-level callbacks are inherited.
>
> It also adds dynamic config gates/limits
(`EnableWorkflowUpdateCallbacks`, `MaxCallbacksPerUpdateID`), updates
`DescribeWorkflow` to surface update callback triggers, extends mutable
state/history builder APIs to carry per-update callback options in
`WorkflowExecutionOptionsUpdated`, and adds `Update.AttachCallbacks`
logic to persist/flush callbacks (including buffering while `stateSent`,
request-id dedup, and stricter validation requiring `request_id` when
callbacks are present).
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
4484fee104. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
---------
Co-authored-by: long-nt-tran <long.tran@temporal.io>
## Summary
Replace the pseudo-version pin of `go.temporal.io/api` with the
freshly-tagged `v1.62.12`. This is a prerequisite for cutting cloud
release 3.156, which requires all OSS dependencies to be on tagged
versions (runbook step 2).
## Details
- `v1.62.12` tags api-go commit
`0a978d4fd72ccadc7666d7f19aa6df9b335b3133` — the same commit the
previous pseudo-version pinned
(`v1.62.12-0.20260511225354-0a978d4fd72c`).
- No source code changes — the module content is identical (the
`/go.mod` h1 hash didn't change in go.sum, only the version-identifier
hash).
- Tag created via `temporalio/api`'s `create-release.yml` workflow.
## Test plan
- [x] `go mod tidy` clean
- [ ] CI passes
## What
Bump `go.temporal.io/api` and add stubs for newly added
`PauseActivityExecution`, `UnpauseActivityExecution`,
`ResetActivityExecution`, and `UpdateActivityExecutionOptions` APIs.
## Why
temporalio/api#743 added these RPCs to
`WorkflowServiceClient`/`WorkflowServiceServer`. Without stubs, any
branch bumping api-go fails to build.
## How did you test it?
`go build ./...` passes.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
## What changed?
Added server-side handling for the new `weak_consistency` flag on
`DescribeNamespaceRequest` (proto change in
https://github.com/temporalio/api/pull/775). When the flag is set,
`DescribeNamespace` is served from the in-memory namespace registry,
bypassing the metadata store. When unset, behavior is unchanged.
## 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).
## How did you test it?
- [X] built
- [X] added new unit test(s)
- [X] added new functional test(s)
## Potential risks
- Eventual consistency on when weak_consistency is set. A namespace
created within the registry's refresh interval may return
`NamespaceNotFound` even though it exists in persistence.
## What
Wire the new `worker_commands` namespace capability to the existing
`WorkerCommandsEnabled` dynamic config flag.
Also bumped the API version.
## Why
SDKs need this capability to know when to create the implicit control
task queue and poller for receiving worker commands
(temporalio/api#771).
## How did you test it?
Unit tests
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
## What changed and Why?
Paired with [api
change](https://github.com/temporalio/api/pull/770/changes)
Define the default time-skipping propagation behavior for current
features: continue-as-new (CAN), child workflows, retry, and reset.
**Group 1 — Inherit both from the current execution:**
- Continue-as-new (CAN): inherits the current config and accumulated
skipped duration; the configured bound is shared across both the
inherited skipped duration and any duration skipped by the new run.
- Child workflows: same behavior as CAN
This design is because CAN is a technical reason to start a new run of
current run, so logically they can be viewed as a same "run". For Child
WFs they can be viewed as an extension of previous workflows or separate
workflows, and in either case, they shall inherit the skipped duration
so that the virtual time doesn't rewind back, and the default behavior
is designed to treat them as an extension of the parent and share the
config. We only consider adding new config to provide flexibility on
demand.
**Group 2 — Inherit from a specific point in history:**
- Retry: inherits the config and skipped duration recorded in the
StartWorkflowExecutionEvent of the current workflow, since retry is
defined as restarting execution from that event
- Cron: same with Retry
**Group3 -- Both inherit from a specific point and catch up of config
change to current**
- Reset: retains the current time-skipping config, since reset is
designed to replay all events up to the reset point and apply any
UpdateWorkflowExecutionOptions changes made after that point — with no
option to exclude them (covered by tests only)
## How did you test it?
- [x] built
- [x] run locally and tested manually
- [x] covered by existing tests
- [x] added new unit test(s)
- [x] added new functional test(s)
## What changed?
Update to latest `go.temporal.io/api` release
## Why?
Prepare for releases
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
Added StartDelay support for standalone activities, mirroring the
existing WithStartDelay behavior on StartWorkflowExecution.
- New start_delay field on ActivityState proto to persist the delay for
retry deadline calculations.
- TransitionScheduled defers the ActivityDispatchTask and extends
ScheduleToStart and ScheduleToClose timeout timers by the delay
duration. StartToClose and Heartbeat timeouts are unaffected.
- Validation rejects negative durations; nil/zero means no delay.
- Changed hasEnoughTimeForRetry to include start delay in the
ScheduleToClose deadline: ScheduleTime + StartDelay +
ScheduleToCloseTimeout. Without this, retries were rejected prematurely
by StartDelay seconds.
## Why?
Start delay is required for standalone activities to support deferred
execution: scheduling work to run after a specified delay. This is a
core capability that workflow start delay already provides, and
standalone activities need parity.
## How did you test it?
- [X] built
- [X] run locally and tested manually
- [X] covered by existing tests
- [X] added new unit test(s)
- [X] added new functional test(s)
