Skip to content

chore(deps): update temporalio/admin-tools docker tag to v1.31.2 - #7

Open
github-actions[bot] wants to merge 1 commit into
mainfrom
renovate/temporalio-admin-tools-1.x
Open

chore(deps): update temporalio/admin-tools docker tag to v1.31.2#7
github-actions[bot] wants to merge 1 commit into
mainfrom
renovate/temporalio-admin-tools-1.x

Conversation

@github-actions

@github-actions github-actions Bot commented May 5, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Update Change
temporalio/admin-tools minor 1.20.0 -> 1.31.2

Release Notes

temporalio/temporal (temporalio/admin-tools)

v1.31.2

Compare Source

What's Changed
  • Bump defaultCliVersion to 1.7.2 for v1.31.1 admin-tools
  • Cherry-pick #​9917, "Cover replication streaming endpoint with authorization"
  • Update Alpine to 3.23.5
Potential Breaking Change

If using authorization with replication setup, set system.disableStreamingAuthorizer dynamic config to true to opt out from changes in this release and avoid replication traffic connection errors. Check the linked CVE for implications of opting out.

Security

Full Changelog: temporalio/temporal@v1.31.1...v1.31.2

v1.31.1

Compare Source

What's Changed

Full Changelog: temporalio/temporal@v1.31.0...v1.31.1

v1.31.0

Compare Source

Schema changes

[!WARNING]
Before upgrading your Temporal Cluster to v1.31.0, you must upgrade core and visibility schema to the following:

  • Core:
    • MySQL schema v1.19
    • PostgreSQL schema v1.19
    • SQLite schema v1.11
  • Visibility:
    • Elasticsearch schema v14
    • MySQL schema v1.14
    • PostgreSQL schema v1.14

Please see our upgrade documentation for the necessary steps to upgrade your schemas.

Please see CHASM section below for more information about the core schema change if you have a custom persistence implementation.

Temporal database schema details

MySQL v1.19, PostgreSQL v1.19, SQLite v1.11 — adds a new current_chasm_executions table for CHASM separate archetype ID spaces:

CREATE TABLE current_chasm_executions(
  shard_id, namespace_id, business_id, archetype_id,
  run_id, create_request_id, state, status, start_version,
  start_time, last_write_version, data, data_encoding,
  PRIMARY KEY (shard_id, namespace_id, business_id, archetype_id)
);
Visibility schema details

MySQL v1.14, PostgreSQL v1.14 — adds TemporalExternalPayloadSizeBytes and TemporalExternalPayloadCount as generated columns with indexes.

Elasticsearch v14 — new index template version with TemporalExternalPayloadSizeBytes and TemporalExternalPayloadCount fields.

CHASM persistence schema change (custom persistence implementations only)

CHASM framework now supports separate businessID spaces for different archetypes and includes corresponding schema changes for SQL core databases. This is achieved by storing multiple current mutable state records in the database, one for each archetype.

If you maintain a custom persistence implementation (Cassandra-based or SQL-based), you must update it to support separate businessID spaces as well. All current mutable state related persistence requests now include a new ArchetypeID field, and your persistence implementation should read or update the current mutable state record for that archetype. Please refer to https://github.com/temporalio/temporal/pull/8907 (Cassandra) or https://github.com/temporalio/temporal/pull/8915 (SQL) for sample changes.

Serverless Workers (pre release)

This version of Temporal Server adds support for Serverless Workers. This feature allows Temporal Workers to run on serverless compute platforms - with AWS Lambda being the first supported platform. Temporal can automatically invoke, scale, and gracefully shut down (scaling to zero, if appropriate) Temporal Workers on your behalf based on workload volume and metrics. See the Serverless Workers documentation to get started.

Invocation is handled by a new server component, the Worker Controller Instance (WCI), which monitors Task Queues and dispatches invocations to a configured compute provider. WCI is disabled by default and must be enabled via the workercontroller.enabled dynamic config key. See Enable the Worker Controller Instance for complete configuration instructions.

Self-hosted setup requires network reachability from the Lambda execution environment to the Temporal frontend, AWS credentials for the server to assume customer IAM roles, and an IAM role in the target account granting lambda:GetFunction and lambda:InvokeFunction. See the self-hosted setup guide for full setup instructions.

Principal Attribution

Adds a server-computed, immutable Principal field to workflow history events, providing trustworthy attribution for "who did this?". Unlike the client-supplied identity field, Principal is derived from authenticated context and cannot be spoofed.

Principal has a Type / Name pair (e.g. jwt/alice@company.com, temporal/internal) and is surfaced in workflow history, CLI, Web UI, and history exports.

The default Authorizer populates Principal from the JWT sub claim. Users with custom Authorizer implementations can populate Principal by setting the new Principal field on authorization.Result.

To enable this feature, set the dynamic config system.enablePrincipalAttribution to true.

Cloud IAM auth for SQL datastores

https://github.com/temporalio/temporal/pull/9879 introduced new passwordCommand config option for SQL datastores as an alternative to the static password field. When set, Temporal executes the specified command and uses its stdout as the database password, re-running the command on each new physical connection so short-lived credentials stay fresh.

This enables IAM-based auth for cloud-managed databases (e.g. AWS RDS, GCP Cloud SQL) by invoking the provider's CLI. For example, configuring the passwordCommand to:

  • aws rds generate-db-auth-token for AWS RDS
  • gcloud sql generate-login-token for GCP Cloud SQL

Supported for MySQL and PostgreSQL. Token lifetime is managed through existing config maxConnLifetime.

Nexus

💥 Overhaul Nexus error model

Complete rework of how Nexus errors are handled and converted (https://github.com/temporalio/temporal/pull/9290).

This change enables Nexus handler errors and operation errors to convey their own messages as opposed to being wrappers for an underlying cause. The change was made to better support Nexus in all languages. There may be slight changes to errors / exception structures in the SDKs.

Remove Nexus feature flag and make Nexus work out of the box

Nexus is now always enabled (https://github.com/temporalio/temporal/pull/9512).

Use token based routing by default with token-based callback routing (https://github.com/temporalio/temporal/pull/9513).

Nexus caller timeouts

Support schedule-to-start and start-to-close timeouts for Nexus operations. SDK upgrade required.

Bug fixes
Metrics

Worker Versioning

Worker Versioning GA

Worker Deployment APIs are now fully GA. The following APIs have been in Public Preview since server v1.28.0. They are now considered GA and users can rely on the signature and behavior consistency going forward.

  • DescribeWorkerDeployment
  • DeleteWorkerDeployment
  • ListWorkerDeployments
  • SetWorkerDeploymentManager
  • DescribeWorkerDeploymentVersion
  • DeleteWorkerDeploymentVersion
  • SetWorkerDeploymentCurrentVersion
  • SetWorkerDeploymentRampingVersion
  • UpdateWorkerDeploymentVersionMetadata
⚠️💥 Sunsetting Worker Versioning V1 (Version Sets) and V2 (Assignment Rules)

The following APIs which have been deprecated since v1.28.0 are now officially sunsetted and their support will be removed in the next server version (v1.32.0). Users should migrate their applications to use the Worker Deployment and Worker Deployment Version APIs instead.

APIs to be removed in v1.32.0:

  • ~~UpdateWorkerBuildIdCompatibility~~
  • ~~GetWorkerBuildIdCompatibility~~
  • ~~UpdateWorkerVersioningRules~~
  • ~~GetWorkerVersioningRules~~
  • ~~GetWorkerTaskReachability~~
New Experimental APIs

The following APIs are added in this release and are in Pre-Release stage as of now. At this stage, the APIs are considered experimental and may see breaking changes in the future:

  • CreateWorkerDeployment
  • CreateWorkerDeploymentVersion
  • UpdateWorkerDeploymentVersionComputeConfig
  • ValidateWorkerDeploymentVersionComputeConfig
Other Changes
  • Add new ContinueAsNew versioning behavior that continues workflows on the ramping version.
  • Fixed bug around stuck workflow after reset when WorkflowUpdate was used.
  • Add deployment name and build ID as separate labels on backlog metrics.
  • Rate-limit worker deployment read APIs and move ListWorkerDeployments to the visibility quota.
  • Cache task queue routing info in the History service to reduce RPC fan-out.
  • Version transition from Drained/Inactive to Draining state upon workflow start/moved via Versioning Override is disabled by default until the implementation is optimized in the next release.
  • Some other minor bug fixes or improvements.

CHASM

  • CHASM framework is enabled by default in this release, but applications built on top of it are NOT enabled by default to allow safe downgrades.
  • CHASM framework now supports separate businessID spaces for different archetypes and includes corresponding schema changes for SQL core databases. See the Schema Changes section above if you maintain a custom persistence implementation.

Standalone Activities

  • Standalone Activities (in public preview) allow activities to run independently of workflows. This feature is gated by the activity.enableStandalone dynamic config flag, which is disabled by default. Set it to true to enable.
  • New APIs and capabilities: DeleteStandaloneActivity API for deleting a standalone activity execution.
  • Durability improvements: server-generated request IDs are now preserved across restarts, a standby task discard handler has been added, and the 1-day retention limit has been removed.
  • PollActivityTaskQueueResponse now includes additional fields needed by workers running without a parent workflow, such as currentAttemptScheduledTime and namespace. Termination and cancellation identity is now propagated through failure info.
  • Multiple timing and retry bugs have been fixed, including the Start-To-Close timeout bug and its metric timestamps, incorrect RetryState for schedule timeouts, and TimerTaskStatus reset issues. Heart beating, RecordActivityTaskStarted, and various error codes also received fixes.
  • Internal task queue name validation has been added for standalone activities and all user-facing APIs.

Task Queue Priority and Fairness GA

  • Task queue priority and fairness features are now GA.
  • As part of that, the new matcher component is enabled by default, which means priority keys are respected by default. The new matcher is fully compatible and switching should be transparent, but if you have any issues you can switch back by setting matching.newUseMatcher to false (affected task queues will reload immediately).
  • As before, fairness can be enabled on a task queue, namespace, or cluster level with the matching.enableFairness dynamic config. Migration between fairness-enabled and fairness-disabled queues is enabled by default.

Cassandra 5 support

  • Temporal Server now supports Cassandra 5.0.4 and later.
  • Cassandra 5 versions earlier than 5.0.4 are not supported.

Archival

  • Custom history and visibility archiver implementations can now be plugged in via the new experimental WithCustomHistoryArchiverFactory and WithCustomVisibilityArchiverFactory server options.
  • Configuration for custom archivers can be supplied under archival.<history|visibility>.provider.customStores.<myScheme> in the server config file, where matches the URI scheme used in your archival URIs (e.g. myScheme://...).
  • See this README for more details.
Helpful links to get you started with Temporal

Temporal Docs
Server
Samples Server
Helm Chart

Docker images

Server
Admin-Tools

Full Changelog: temporalio/temporal@v1.30.4...v1.31.0

v1.30.6

Compare Source

What's Changed

Potential Breaking Change

If using authorization with replication setup, set system.disableStreamingAuthorizer dynamic config to true to opt out from changes in this release and avoid replication traffic connection errors. Check the linked CVE for implications of opting out.

Security

Full Changelog: temporalio/temporal@v1.30.5...v1.30.6

v1.30.5

Compare Source

What's Changed

Full Changelog: temporalio/temporal@v1.30.4.1...v1.30.5

v1.30.4

Compare Source

What's Changed

Potential Breaking Change

If using authorization with replication setup, set system.disableStreamingAuthorizer dynamic config to true to opt out from changes in this release and avoid replication traffic connection errors. Check the linked CVE for implications of opting out.

Security

Full Changelog: temporalio/temporal@v1.30.3...v1.30.4

Helpful links to get you started with Temporal

Temporal Docs
Server
Helm Chart

Docker images for this release (use the tag 1.30.4)

Server
Admin-Tools

v1.30.3

Compare Source

What's Changed

Security

Full Changelog: temporalio/temporal@v1.30.2...v1.30.3

Helpful links to get you started with Temporal

Temporal Docs
Server
Helm Chart

Docker images for this release (use the tag 1.30.3)

Server
Admin-Tools

v1.30.2

Compare Source

What's Changed

Worker Versioning
  • Upgrade-on-Continue-as-New (Public Preview) - New feature enables Pinned workflows to find out when a new worker version is available for them to upgrade to. Use this to Pin long-running workflows and let them upgrade-on-continue-as-new to the Target Worker Deployment Version (#​9239)
  • System protection caches to reduce excessive GetTaskQueueUserData lookups (#​9168, #​9262)
  • Track version drainage properly with VersioningOverride for automated worker controllers (#​9147)
  • Fix approximate_backlog_count metric for Current and Ramping version tasks (#​9300, #​9316, #​8957)
  • Fix task rescheduling edge case during AutoUpgrade Transition (#​9250)
Bug Fixes
  • Fix bug in retrieving archived workflows from Google Cloud Store (#​9329)
  • Fix race in fairTaskReader (#​9467)
  • Bump Temporal CLI version to 1.6.1 in Docker image build (#​9433)
Security

Full Changelog: temporalio/temporal@v1.30.1...v1.30.2

Helpful links to get you started with Temporal

Temporal Docs Server Docker Compose Helm Chart

Docker images for this release (use the tag 1.30.2)

Server Server With Auto Setup (what is Auto-Setup?) Admin-Tools

v1.30.1

Compare Source

⚠️💥 DOCKER IMAGE BREAKING CHANGES 💥⚠️

Starting in this release, for security reasons, Temporal Docker images have been slimmed down, and we have removed binaries and packages that do not strictly need to be included. This includes:

temporalio/admin-tools

Removed tools:

  • bash
  • python3
  • libev
  • curl
  • jq
  • yq
  • mysql-client
  • postgresql-client
  • expat
  • tini
  • cqlsh
  • tctl
  • tctl-authorization-plugin

Added tools:

  • temporal-elasticsearch-tool

temporal cli still exists in the admin-tools image

temporalio/server

Removed components:

  • temporal CLI
  • tctl and tctl-authorization-plugin (both deprecated)
  • dockerize
  • curl
  • bash
dockerize → embedded sprig

Previous behavior:

  • dockerize processed a persistent config template
  • The template lived in the image but could be overridden via volume mounts
  • dockerize provided sprig + custom helper functions
  • The server binary would search a set of paths for the rendered config file

New behavior:

  • sprig templating is now built directly into the server binary
  • The default config template is embedded in the binary
  • dockerize is fully removed as an image dependency
  • TEMPORAL_SERVER_CONFIG_FILE_PATH is used to reference the config file. When not specified, the embedded template is processed.
  • # enable-template is required at the top of the config file to enable sprig templating.

References:

Image deprecations

The following images are deprecated and will no longer receive updates:

  • temporalio/auto-setup
    • For local development, we recommend using the CLI dev server.
    • See Samples Server for examples of how to use different persistence and visibility stores.
  • temporalio/base-admin-tools
  • temporalio/base-server
  • temporalio/base-ci-builder
  • temporalio/base-builder

⚠️💥 Helm Chart BREAKING CHANGES 💥⚠️

Due to the Docker image breaking changes above, you must now use a minimum Helm chart version of temporal-0.73.2.

Configuration Options
Value Description Default
server.useEntrypointScript Use an entrypoint script that auto-detects dockerize vs sprig false
server.configMapsToMount Which config template to mount: dockerize, sprig, or both dockerize
server.setConfigFilePath Set TEMPORAL_SERVER_CONFIG_FILE_PATH env var (required for sprig) false
Configuration for Different Scenarios

Option 1: Support both pre-1.30 and 1.30+ images (recommended for CI/testing)

server:
  useEntrypointScript: true
  configMapsToMount: "both"
  setConfigFilePath: false

Option 2: 1.30+ only (sprig templating)

server:
  image:
    tag: "1.30.1" # or later
  useEntrypointScript: false
  configMapsToMount: "sprig"
  setConfigFilePath: true

Option 3: Pre-1.30 only (dockerize, deprecated)

server:
  image:
    tag: "1.29.3" # or earlier
  useEntrypointScript: false
  configMapsToMount: "dockerize"
  setConfigFilePath: false

⚠️ Behavioral / Potentially Breaking Change

Retry behavior of PermissionDenied for Nexus operations

The retry behavior for PermissionDenied errors when scheduling a Nexus operation has been updated.

  • Previously, these errors were not retried. With this change, PermissionDenied is now considered retryable.
  • Impact:
    • OSS users who inject their own custom Nexus registries may notice different retry patterns for PermissionDenied errors.
  • We are considering adding a dynamic config flag to control this behavior.
metrics.Tag interface-to-struct conversion

metrics.Tag is changing from an interface to a concrete type, and tag Key() and Value() reader methods are being replaced with exported Key and Value fields. metrics.Handler methods that accept tags now only accept the concrete type.

If you build your own temporal server with a custom metrics handler temporal.WithCustomMetricsHandler(metricsHandler), you need to update that handler to read metrics.Tag keys and values via exported Key and Value fields. If you provide a custom metrics.Tag interface implementation, you need to replace that implementation with a concrete metrics.Tag, for example by using metrics.StringTag.

Default system.enableCrossNamespaceCommands dynamic configuration value

system.enableCrossNamespaceCommands controls if a workflow can schedule a command to start childworkflow, cancel or signal another workflow in a different namespace. This feature is deprecated and the default value changed from true to false in this release. If your workload relying on this feature, please add an explicitly dynamic config override and set the value for this key to be true.

⚠️ Worker Versioning

[!WARNING]
Note — Worker Versioning users only
If you are using the Worker Deployment API SetWorkerDeploymentCurrentVersion and need to roll back after upgrading to v1.30.1, roll back to v1.29.3 or newer (not an older version). Rolling back to a version older than v1.29.3 after calling SetWorkerDeploymentCurrentVersion in v1.30.1 will cause a panic in ListWorkerDeployments.
To preserve this rollback safety guarantee, upgrade to v1.29.3 before upgrading to v1.30.1.
If you are not using Worker Versioning, or not rolling back, this does not apply to you.

  • Improved reliability and safety:
    • Made APIs significantly more robust and scalable by propagating routing config to task queues asynchronously.
      • [⚠️ Behavioral Change] In cases where you want to wait until all partitions of all task queues are aware of your latest Routing Config change (i.e., latest Current or Ramping Version) before taking an action, you must now ensure that WorkerDeploymentInfo.RoutingConfigUpdateState == ROUTING_CONFIG_UPDATE_STATE_COMPLETED after SetCurrentVersion or SetRampingVersion API calls complete. Previously, those APIs returned success only after that condition was true, but now propagation completes asynchronously. In general, users need not be concerned with this change, but this behavior change is being noted for awareness.
    • [⚠️ Behavioral Change] Reject Versioning Override for versions that do not exist.
    • New safety mechanism (revision number) to guarantee that auto-upgrade workflows never accidentally use an outdated version if they switch task queue partitions.
  • Improved observability and ease of use:
    • New TemporalUsedWorkerVersions search attribute, which shows which Worker Deployment Versions a workflow has used during its lifetime.
    • Improved accuracy and tagging of metrics.
    • Improved error messages (added Worker Deployment name, Build ID, and other info to error messages where relevant).
    • WorkflowExecutionOptionsUpdated history event now contains the identity of the client that changed the options (i.e., to set/unset a Versioning Override).
  • New capabilities:
    • LastCurrentTime timestamp in version info tells you whether a version was ever promoted to Current in the past. This enables accelerated rollout of versions that have been Current in the recent past by allowing the controller to detect whether a rollout is actually a rollback.
    • If a workflow is already Pinned, you can now set a Pinned Versioning Override without specifying a pinned version (easier for batch jobs setting Pinned Versioning Override on a large batch of workflows running on different versions).
  • Bug fixes:

Task Queue Priority & Fairness Public Preview

  • Task Queue Priority and Fairness (initially introduced in 1.29) are now in Public Preview.
  • To enable Priority on a task queue, namespace, or globally, set dynamic config matching.useNewMatcher to true.
  • To enable Fairness on a task queue, namespace, or globally, set dynamic configs matching.useNewMatcher, matching.enableFairness, and matching.enableMigration to true.

Examples:
Priority (task queue scoped)

matching.useNewMatcher:
  - value: true
    constraints:
      namespace: "my-namespace"
      taskQueueName: "my-task-queue"

Fairness (task queue scoped):

matching.useNewMatcher:
  - value: true
    constraints:
      namespace: "my-namespace"
      taskQueueName: "my-task-queue"
matching.enableFairness:
  - value: true
    constraints:
      namespace: "my-namespace"
      taskQueueName: "my-task-queue"
matching.enableMigration:
  - value: true
    constraints:
      namespace: "my-namespace"
      taskQueueName: "my-task-queue"
  • Changes since 1.29:
    • Fairness weight overrides can be set through the API.
    • Priority metadata can be updated on existing workflows and activities through UpdateWorkflowExecutionOptions and UpdateActivityOptions. Affected tasks are rescheduled.
    • The approximate_backlog_count metric now has a task_priority label.
    • Polls to sticky queues are redirected to higher-priority backlog tasks on normal partitions. This is enabled by default, but can be disabled with dynamic configs matching.priorityBacklogForwarding and matching.ephemeralDataUpdateInterval.
    • Fairness can be turned on for active task queues without losing tasks. Previously backlogged tasks are dispatched first. Ensure dynamic config matching.enableMigration is enabled before, or at the same time as, enabling fairness.
    • Fairness can be configured to switch on automatically on usage of fairness keys. Enable dynamic config matching.autoEnableV2.

Degraded Workflow Visibility

  • system.numConsecutiveWorkflowTaskProblemsToTriggerSearchAttribute is a new dynamic config value to turn on degraded workflow visibility. Setting this to 0 turns off the feature entirely; any positive integer value becomes the number of consecutive workflow task failures needed to add the TemporalReportedProblems search attribute.
  • TemporalReportedProblems is a new search attribute to identify workflows that are not making progress. The search attribute is a KeywordList with two entries: a cause and a category. The cause is either WorkflowTaskFailed or WorkflowTaskTimedOut. If the cause is WorkflowTaskFailed, the category is one of the following values. If the cause is WorkflowTaskTimedOut, the category is always ScheduleToClose.
  • See documentation here

External payloads

history.externalPayloadsEnabled is a new dynamic config value that enables server-side support for the claim-check pattern, where payloads are stored in external storage outside of history. When enabled, the server produces the aggregate size and count of external payloads and returns ExternalPayloadSizeBytes and ExternalPayloadCount on the DescribeWorkflowExecution call. This feature depends on claim-check pattern support in the Temporal SDK, which is currently under development.

Visibility with OpenSearch

Temporal can now run with OpenSearch 2+ as a visibility store. You only need to set up Temporal config as you would for Elasticsearch (see the provided Elasticsearch config template).

Increasing the maximum number of custom search attributes

You can now change the maximum number of custom search attributes when using a SQL database as the visibility store. Previously, there was a hard-coded amount of pre-allocated fields that could be used to create custom search attributes. Now, you can change the maximum number of pre-allocated fields.

Example: assuming you have the default schema provided by Temporal and you want to increase the number of Int-type custom search attributes from 3 to 5 and Keyword-type from 10 to 12, follow the steps below:

  1. Change your DB schema by adding the necessary columns.

    1. MySQL (check the existing schema definition, and copy the syntax for the respective search attribute type):

      ALTER TABLE custom_search_attributes
  ADD COLUMN Int04     BIGINT       GENERATED ALWAYS AS (search_attributes->"$.Int04"),
  ADD COLUMN Int05     BIGINT       GENERATED ALWAYS AS (search_attributes->"$.Int05"),
  ADD COLUMN Keyword11 VARCHAR(255) GENERATED ALWAYS AS (search_attributes->>"$.Keyword11"),
  ADD COLUMN Keyword12 VARCHAR(255) GENERATED ALWAYS AS (search_attributes->>"$.Keyword12");

ALTER TABLE custom_search_attributes
  ADD INDEX by_int_04     ON custom_search_attributes (namespace_id, Int04),
  ADD INDEX by_int_05     ON custom_search_attributes (namespace_id, Int05),
  ADD INDEX by_keyword_11 ON custom_search_attributes (namespace_id, Keyword11),
  ADD INDEX by_keyword_12 ON custom_search_attributes (namespace_id, Keyword12);

    2. PostgreSQL (check the existing schema definition, and copy the syntax for the respective search attribute type):

      ALTER TABLE executions_visibility
  ADD COLUMN Int04     BIGINT       GENERATED ALWAYS AS ((search_attributes->'Int04')::bigint),
  ADD COLUMN Int05     BIGINT       GENERATED ALWAYS AS ((search_attributes->'Int05')::bigint),
  ADD COLUMN Keyword11 VARCHAR(255) GENERATED ALWAYS AS (search_attributes->>'Keyword11'),
  ADD COLUMN Keyword12 VARCHAR(255) GENERATED ALWAYS AS (search_attributes->>'Keyword12');

ALTER TABLE executions_visibility
  ADD INDEX by_int_04     ON executions_visibility (namespace_id, Int04,     (COALESCE(close_time, '9999-12-31 23:59:59')) DESC, start_time DESC, run_id),
  ADD INDEX by_int_05     ON executions_visibility (namespace_id, Int05,     (COALESCE(close_time, '9999-12-31 23:59:59')) DESC, start_time DESC, run_id),
  ADD INDEX by_keyword_11 ON executions_visibility (namespace_id, Keyword11, (COALESCE(close_time, '9999-12-31 23:59:59')) DESC, start_time DESC, run_id),
  ADD INDEX by_keyword_12 ON executions_visibility (namespace_id, Keyword12, (COALESCE(close_time, '9999-12-31 23:59:59')) DESC, start_time DESC, run_id);

  2. Modify the Temporal config file:

    persistence:
  visibilityStore: ...

visibility:
  persistenceCustomSearchAttributes:
    Int: 5
    Keyword: 12

  3. Restart Temporal.

You can only increase the maximum number of pre-allocated fields. Reducing the maximum number in the config is a no-op. Do not drop columns from your database table.

Visibility Query Converter

We are introducing a new experimental query converter to replace the existing ones. Currently, there are two query converter implementations: one for Elasticsearch, which builds the query search body; and one for SQL, which mainly validates the query. The new query converter unifies these implementations such that each Visibility Store implementation can implement the StoreQueryConverter interface to build its query object without needing to implement parsing and validation.

The new unified query converter is not 100% backward compatible with the existing query converter for Elasticsearch. In other words, if you use Elasticsearch as your visibility store, some queries might not work.

In particular, the new query converter performs stricter validation of query clauses and does not allow comparisons between a search attribute and a value of a different type. For example, the existing query converter for Elasticsearch allows comparing a Keyword-type search attribute with an integer (e.g., WorkflowType = 123), but the new query converter returns an error.

Since this is still experimental, the new unified query converter is disabled by default and can be enabled by setting the dynamic config system.visibilityEnableUnifiedQueryConverter: true. Once the new query converter is production-ready, it will be enabled by default (projected: v1.31.0), and the old ones will be deprecated and removed (projected: v1.32.0).

Elasticsearch tool

Temporal now provides an experimental temporal-elasticsearch-tool to manage visibility templates and indexes. The tool supports the same authentication and AWS request-signing features as the Temporal server. See the README for usage details.

Internal Nexus Callback Routing

This simplifies Nexus callback configuration by introducing internal routing for worker-targeted operations, eliminating the need for callback URL templates and allowlist configuration in normal deployments.

New useSystemCallbackURL Toggle (component.nexusoperations.useSystemCallbackURL)
  • When enabled, worker-targeted Nexus operations use a fixed temporal://system callback URL instead of requiring a configured URL template
  • External endpoint targets continue to use template-generated URLs
  • Default: false (will change to true in a future release)
Automatic temporal://system Allowlisting
  • The temporal://system URL is now always permitted by callback address validation, regardless of configured component.callbacks.allowedAddresses rules
  • No explicit allowlist entry is needed for internal worker callbacks
Dynamic Config Examples

Before (required configuration):

system.enableNexus:
  - value: true
component.nexusoperations.callback.endpoint.template:
  - value: http://localhost:7233/namespaces/.NamespaceName/nexus/callback
component.callbacks.allowedAddresses:
  - value:
      - Pattern: "*"
        AllowInsecure: true

After (zero config for worker targets):

system.enableNexus:
  - value: true
component.nexusoperations.useSystemCallbackURL:
  - value: true
Migration Notes

When useSystemCallbackURL is enabled, your HTTPCallerProvider must route internal requests using the Source and Token headers, overriding the path to /nexus/callback. See components/callbacks/request.go for the routing implementation.

Dynamic Config Changes

Nexus
  • component.nexusoperations.limit.operation.timeout.min has been renamed to component.nexusoperations.limit.request.timeout.min, and given a default value of 500ms.
  • A new config, component.nexusoperations.limit.dispatch.task.timeout.min, has been added with a default value of 1s. This is the minimum time remaining for a request to be dispatched to the handler worker. If the remaining request timeout is less than this value, a timeout error is returned. Working in conjunction with MinRequestTimeout, both configs help ensure that the server has enough time to complete a Nexus request.

Helpful links to get you started with Temporal

Temporal Docs
Server
Samples Server
Helm Chart

Docker images

Server
Admin-Tools

Full Changelog: temporalio/temporal@v1.30.0...v1.30.1

v1.29.6

Compare Source

What's Changed

Potential Breaking Change

If using authorization with replication setup, set system.disableStreamingAuthorizer dynamic config to true to opt out from changes in this release and avoid replication traffic connection errors. Check the linked CVE for implications of opting out.

Security

Full Changelog: temporalio/temporal@v1.29.5...v1.29.6

Helpful links to get you started with Temporal

Temporal Docs
Server
Helm Chart

Docker images for this release (use the tag 1.29.6)

Server
Server With Auto Setup (what is Auto-Setup?)
Admin-Tools

v1.29.4

Compare Source

What's Changed

Dependency Updates and Ignore Unknown Predefined Search Attributes After Rollback from v1.30.1

Helpful links to get you started with Temporal

Temporal Docs
Server
Samples Server
Helm Chart

Docker images

Server
Admin-Tools

Full Changelog: temporalio/temporal@v1.29.3...v1.29.4

v1.28.3

Compare Source

What's Changed

This patch addresses multiple CVEs in Go dependencies and updates the Elasticsearch image:

  • Bump golang.org/x/crypto v0.37.0 → v0.45.0 (GO-2025-4116, GO-2025-4134, GO-2025-4135)
  • Bump golang.org/x/net v0.39.0 → v0.47.0 (GO-2026-4440, GO-2026-4441)
  • Bump Go 1.24.5 → 1.24.13 for stdlib CVE fixes (crypto/tls, crypto/x509)
  • Bump Elasticsearch image to 8.5.0 (#​9497)

Full Changelog: temporalio/temporal@v1.28.2...v1.28.3

Helpful links to get you started with Temporal

Temporal Docs
Server
Docker Compose
Helm Chart

Docker images for this release

Server (use the tag 1.28.3)
Server With Auto Setup (what is Auto-Setup?)
Admin-Tools

v1.27.1

Compare Source

Schema Changes

Before upgrading your Temporal Cluster to v1.27.1, you must upgrade your core schema if you are using MySQL or PostgreSQL, and your visibility schema to the following:

  • Core:
    • MySQL schema v1.16
    • PostgreSQL schema v1.16
  • Visibility:
    • Elasticsearch schema v9
    • MySQL schema 1.9
    • PostgreSQL schema v1.9

Please see our upgrade documentation for the necessary steps to upgrade your schemas.

NOTE: The upgrade to MySQL and PostgreSQL Visibility schemas may come with temporary performance degradation because of creation of a new column _version which has default values. Consider performing the schema upgrades when load is low. There are protective mechanisms in place to account for timeouts from any VisibilityStore.

Deprecation of Visibility Scan APIs

Visibility Scan APIs have been deprecated in favor of List Workflow APIs. Visibility Scan APIs will be removed in a future version. Migration to List Workflow APIs will be required in future versions.

Nexus GA

Nexus is now GA with a stable server API.

Read more here on how to disable Nexus or how to operate it here.

Notable features and bug fixes since v1.26.2:

  • The server now allows a maximum of 30 pending Nexus operations per workflow by default, as opposed to the previous limit being 30 total.
  • Add support for attaching callbacks, request IDs, and links to a workflow via StartWorkflowExecutionRequest.OnConflictOptions with WorkflowIdConflictPolicy of USE_EXISTING. This allows multiple operations to be backed by the same workflow.
  • Misc small features and tests.

Safe Deploys

The following APIs are added for Worker Versioning. All APIs are experimental and not yet recommended for production usage. You need to set the dynamic configs system.enableDeployments and system.enableDeploymentVersions in order to use them.

  • ListWorkerDeployments
  • DescribeWorkerDeployment
  • DescribeWorkerDeploymentVersion
  • SetWorkerDeploymentCurrentVersion
  • SetWorkerDeploymentRampingVersion
  • UpdateWorkerVersionMetadata
  • DeleteWorkerDeployment
  • DeleteWorkerDeploymentVersion

The following APIs are now deprecated and replaced by above:

  • ~~DescribeDeployment~~
  • ~~ListDeployments~~
  • ~~GetDeploymentReachability~~
  • ~~GetCurrentDeployment~~
  • ~~SetCurrentDeployment~~

Activity Commands (pre-release)

Changes to the Activity Commands — a set of APIs designed to resolve issues related to activity execution. The following APIs where updated:

  • UpdateActivityOptionsById was renamed to UpdateActivityOptions. This API can be used by the client to update the options of an activity while activity is running.
  • PauseActivityById was renamed to PauseActivity. With this API, If the Activity is not currently running (e.g. because it previously failed and is waiting for the next retry), it will not be run again until it is unpaused.
    • activity_type parameter was added. If this parameter is set - all running activities of this type will be paused.
  • UnpauseActivityById was renamed to UnpauseActivity. With this API clients can re-schedule a previously-paused Activity for execution.
    • no_wait parameter was removed
    • activity_type parameter was added. If this parameter is set - all paused activities of this type will be unpaused.
    • match-all parameter was added. If this parameter is set - all paused activities will be unpaused.
    • jitter parameter was added. If set, the activity will start at a random time within the specified jitter duration.
  • ResetActivityById was renamed to ResetActivity. With this API clients can reset the execution of an activity, specified by its ID or type.
    • no_wait parameter was removed
    • activity_type parameter was added. If this parameter is provided - all paused activities of this type will be unpaused.
    • keep_paused parameter was added. If this parameter is provided - all paused activities will stay paused. Otherwise they will be unpaused.
    • jitter parameter was added. If set, the activity will start at a random time within the specified jitter duration.
  • New batch operation was introduced - BatchOperationUnpauseActivities.

Workflow Reset with children

In this release we have added the functionality to reset a workflow with a pending child.

Prior to this release reseting to a point between child workflow initiated and child workflow completed was not supported (the reset operation would fail). In the current release the reset operation will allow this case and the behavior of the parent after reset is to reconnect to the running child. The new run of the parent will receive the child’s completion event and result (if any) from the child.

The feature is gated behind a per namespace boolean dynamic configuration AllowResetWithPendingChildren which is enabled by default for all namespaces.

Note: If you are using Go-SDK and are relying on the SDK to generate child workflow IDs then you need to update it to the latest version to be able to use this feature. Other SDKs don’t need any upgrade to use this feature.

Delete namespace improvement

  1. Delete workflow executions RPS is now dynamic. Previously, frontend.deleteNamespaceDeleteActivityRPS was read only once when namespace deletion started, and subsequent changes to this dynamic config didn't affect the ongoing deletion. This was inconvenient for large namespaces since the default RPS is only 100. Now the RPS can be adjusted on the fly.

    Please note: Since deletion of Workflow Execution is an asynchronous process, this RPS controls the rate at which delete execution tasks are created. Decreasing this value (for example, from 1000 to 10) won't immediately slow down the process, as existing tasks in the transfer queue must be processed first.

  2. DeleteExecutionsWorkflow now supports a stats query to track its progress. Since this Workflow can run for hours after a namespace is marked as deleted, it was previously difficult to monitor how many Workflow Executions remained. The new query handler provides current statistics about total and remaining executions.

  3. Metrics and logging have been enhanced for better actionability. Key improvements include:

    1. Monitor ReclaimResources workflow failures using the metrics reclaim_resources_namespace_delete_failure and reclaim_resources_delete_executions_failure.
    2. Track DeleteExecutionsWorkflow progress using the metrics delete_executions_success and delete_executions_failure.

  4. Business critical namespaces can be protected from deletion. Use dynamic config to list namespaces which are not deletable:

    worker.protectedNamespaces:
  - value:
      - critical_namespace
      - just_very_important_namespace

  5. Sleep duration in ReclaimResourcesWorkflow now supports dynamic changes. If a namespace delete delay was mistakenly set too long, you can now modify it after the Workflow has started. Use this command to update the delay to a new value (10 hours in this example):

    temporal workflow update --namespace temporal-system --name update_namespace_delete_delay --workflow-id temporal-sys-reclaim-namespace-resources-workflow/default-deleted-93f5e --input '"10h"'

    Or use this command to remove the delay entirely:

    temporal workflow update --namespace temporal-system --name update_namespace_delete_delay --workflow-id temporal-sys-reclaim-namespace-resources-workflow/default-deleted-93f5e --input '"0"'

    Please note: The new delay starts from when it is set, not from when the original timer was created. For example, if the Workflow has already slept for 2 hours and the timer is updated to 10h, it will sleep for another 10 hours, not 8.

Scheduled Actions

  • Scheduler workflow version has been updated.
    • FutureActionTimes now accounts for a schedule’s update time and RemainingActions.
    • ScheduleActionResult now includes a WorkflowExecutionStatus field, providing an eventually-consistent view of a workflow’s status within List results.
  • Bugfix: Queries on schedules might have been delayed after dynamic config changes were applied to per-namespace workers. An anti-entropy mechanism has been added to the per-namespace worker component.

Fix out-of-order Visibility tasks with SQL database

All SQL stores used for Visibility had the rare possibility to perform updates to a workflow's visibility state out-of-order. This could result in Workflows occasionally appearing to have state that is out of date.

Implementation

This has been fixed by adding a new column

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

@github-actions
github-actions Bot force-pushed the renovate/temporalio-admin-tools-1.x branch 2 times, most recently from 8c7c2fa to ec73a0c Compare May 6, 2026 18:46
@github-actions
github-actions Bot force-pushed the renovate/temporalio-admin-tools-1.x branch 3 times, most recently from fd0f0b6 to 95b96d4 Compare June 10, 2026 19:07
@github-actions github-actions Bot changed the title chore(deps): update temporalio/admin-tools docker tag to v1.31.0 chore(deps): update temporalio/admin-tools docker tag to v1.31.1 Jun 10, 2026
@github-actions
github-actions Bot force-pushed the renovate/temporalio-admin-tools-1.x branch from 95b96d4 to 617ac2c Compare July 9, 2026 10:04
@github-actions github-actions Bot changed the title chore(deps): update temporalio/admin-tools docker tag to v1.31.1 chore(deps): update temporalio/admin-tools docker tag to v1.31.2 Jul 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants