Visibility schema changes

TemporalPauseInfo column was added to visibility. TemporalPauseInfo contains search attribute related to paused entities in temporal workflows.

Before upgrading your Temporal Cluster to v1.26.2, you must upgrade your visibility schemas to the following:

• Visibility:
  • Elasticsearch schema v8
  • MySQL schema 1.7
  • PostgreSQL schema v1.7

Batch metrics (wide events)

PR: https://github.com/temporalio/temporal/pull/6655

Description: Extended metrics.Handler interface with a new StartBatch method. StartBatch returns a BatchHandler that can be used to send a sequence of metrics as a single event when Close() is called on the batch. All provided metric handlers have been updated with the new interface and simply send metrics individually.

💥 BREAKING CHANGE 💥 If you provide a custom metrics handler with temporal.WithCustomMetricsHandler(metricsHandler) you will need to implement StartBatch() on that handler. See the tally metrics handler for an example of this.

Versioning / safe deploy (pre-release)

The following EXPERIMENTAL Versioning APIs are added in this release:

• Deployment APIs, for managing worker deployments:
  • DescribeDeployment
  • ListDeployments
  • GetCurrentDeployment
  • SetCurrentDeployment
  • GetDeploymentReachability
• UpdateWorkflowExecutionOptions API (and its batch mode) for setting versioning override for executions.

Documentation is not available at this point. Do not use above APIs in production.

To enable these APIs the following configs should be enabled: system.enableDeployments and frontend.workerVersioningWorkflowAPIs.

Workflow Update GA

Description:

Workflow Update enables a gRPC client of a Workflow Execution to issue requests to that Workflow Execution and receive a response. These requests are delivered to and processed by a client-specified Workflow Execution. Updates are differentiated from Queries in that the processing of an Update is allowed to modify the state of a Workflow Execution. Updates are different from Signals in that an Update returns a response.

Any gRPC client can invoke Updates via the WorkflowService.UpdateWorkflowExecution. Additionally, past Update requests can be observed via the WorkflowService.PollWorkflowExecutionUpdate API. The wait stage option determines whether they respond once the Update was accepted or completed.

Note that an Update only becomes durable when it was accepted, until then, it will not appear in the Workflow history. SDKs will automatically retry to ensure Update requests complete.

The execution and retention of Updates is configured via two optional dynamic configuration values:

• history.maxTotalUpdates controls the total number of Updates that a single Workflow Execution can support. The default is 2000.
• history.maxInFlightUpdates controls the number of Updates that can be “in-flight” (that is, concurrently executing, not having completed) for a given Workflow Execution. The default is 10.

Since the 1.25 release, several minor bugs have been fixed.

Workflow Update-With-Start (public preview)

Update-With-Start sends a Workflow Update that checks whether an already-running Workflow with that ID exists. If it does, the Update is processed. If not, it starts a new Workflow Execution with the supplied ID. When starting a new Workflow, it immediately processes the Update.

Update-With-Start is great for latency-sensitive use cases.

Activity API (pre-release)

Description:

We introduce the Activity API — a set of APIs designed to resolve issues related to activity execution. The following APIs where introduced:

• UpdateActivityOptionsById. This API can be used by the client to update the options of an activity while activity is running.
  • The following options are supported:
    • task-queue
    • schedule-to-close-timeout
    • schedule-to-start-timeout
    • start-to-close-timeout
    • heartbeat-timeout
    • retry-initial-interval
    • retry-maximum-interval
    • retry-backoff-coefficient
    • retry-maximum-attempts
  • Partial updates are supported.
  • Timeout updates are effective immediately.
• PauseActivityById. 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.
  • However, if the Activity is currently running, it will run to completion. If the Activity is on its last retry attempt and fails, the failure will be returned to the caller, just as if the Activity had not been paused. Otherwise, if it fails, it will enter a paused state.
• UnpauseActivityById . With this API clients can re-schedule a previously-paused Activity for execution.
  • If the Activity is not running and has exceeded its retry timeout, it will be scheduled immediately. Otherwise, it will be scheduled when its retry timeout expires. The Activity can be retried immediately using --no-wait.
• ResetActivityById. With this API clients can unpauses the execution of a previously paused activity, specified by its ID.
  • Resetting an activity means:
    • number of attempts will be reset to 0.
    • activity timeouts will be reset.

Documentation is not available at this point. Do not use above APIs in production.

Nexus

Nexus is still in public preview for this release, but has now been enabled by default.

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

Notable features and bug fixes since v1.25.2:

• Allow completing a Nexus operation after workflow reset (#6434).
• Fix a few issues around replication and cancelation.
• Record NexusOperationStarted event and link when async operation completion races with the sync response path.
• Support for full Temporal Failure rehydration and encryption. Nexus handlers and workflows backing operations will now expose the full error details by default. Caller workflows will also rehydrate the original error to allow for better E2E debugging experience.
• Allow skipping application of Nexus events when resetting a workflow.

Notable bug fixes

Primary engineer: @prathyushpv

Table not found bug in sqlite.

Durations with mismatched seconds and nanoseconds signs will now fail validation and return an InvalidArgument error.

Helpful links to get you started with Temporal

Temporal Docs Server Docker Compose Helm Chart

Docker images for this release (use the tag 1.26.2)

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

Full Changelog: https://github.com/temporalio/temporal/compare/v1.25.2...v1.26.2