This release adds a new feature called Worker Heartbeating. This feature spins up a single nexus-only worker per Client/Namespace in the background and periodically sends some basic metrics over to server for all of the workers registered on the same Client/Namespace.
Server version 1.29.1 and newer supports this feature. This feature will be enabled by default, although this currently requires a server dynamic config flag, --dynamic-config-value frontend.WorkerHeartbeatsEnabled=true to enable. Currently, the only way to interact with this new data is to also enable the flag --dynamic-config-value frontend.ListWorkersEnabled=true, then use CLI commands temporal worker list and temporal worker describe to query the data. If heartbeating is enabled with a server version older or with the config flag off, a single warning log Worker heartbeating configured for runtime, but server version does not support it. on worker startup will emit.
💥 With the introduction of Worker Heartbeats, we’ve deprecated the contrib/resourcetuner lib, and instead created a new contrib/sysinfo lib. The resource tuner now lives in the worker package.
Note: Requires Temporal Server version 1.31.0 or later.
This release of the Go SDK includes a number of enhancements to error serialization for synchronous operations.
nexus.HandlerError can now include its own message (and stack trace if the language supports it) independent from the causenexus.OperationError can now include its own message (and stack trace if the language supports it) independent from the causenexus.OperationError is now included in the error chain when a synchronous operation handler returns a nexus.OperationError . The nexus.OperationError will be translated to an appropriate Temporal error based on the state of the error. Previously this error was not included in the error chain.
OperationStateFailed will be translated to an ApplicationErrorOperationStateCancelled will be translated to an CanceledErrorThese changes only effect synchronous operations. There is no change to errors for asynchronous operations like starting a workflow.
Note: Requires Temporal Server version 1.31.0 or later.
This release of the Go SDK adds more timeout options on NexusOperationOptions to control how long the caller wants to wait on different stages of the operation.
The Schedule-to-Start timeout limits how long the caller will wait for the Operation to be started by the handler. If not set, no Schedule-to-Start timeout is enforced.
fut := c.ExecuteOperation(ctx, service.HelloOperationName, service.HelloInput{Name: name, Language: language}, workflow.NexusOperationOptions{
ScheduleToStartTimeout: 2 * time.Minute,
})
The Start-to-Close timeout limits how long the caller will wait for an asynchronous Operation to complete after it has been started. This timeout only applies to asynchronous Operations. If not set, no Start-to-Close timeout is enforced.
fut := c.ExecuteOperation(ctx, service.HelloOperationName, service.HelloInput{Name: name, Language: language}, workflow.NexusOperationOptions{
StartToCloseTimeout: 5 * time.Minute,
})
Added support for workflows to detect when their target deployment version has changed and opt into upgrading via continue-as-new. New APIs:
This enables a "trampolining" pattern: a pinned workflow detects a version change, then continues-as-new with auto-upgrade to seamlessly move to the latest deployment version. Both detection and action are fully opt-in, avoiding accidental infinite CAN loops.
Full Changelog: https://github.com/temporalio/sdk-go/compare/v1.40.0...v1.41.0
Fetched April 11, 2026