chore(deps): update temporalio/server docker tag to v1.25.0 #2976
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
1.24.2
->1.25.0
Release Notes
temporalio/temporal (temporalio/server)
v1.25.0
Compare Source
Schema changes
Before upgrading your Temporal Cluster to v1.25.0, you must upgrade your core and visibility schemas to the following:
Please see our upgrade documentation for the necessary steps to upgrade your schemas.
Release Highlights
1. Nexus
Nexus RPC is an open-source service framework for arbitrary-length operations whose lifetime may extend beyond a traditional RPC. It is an underpinning connecting durable executions within and across namespaces, clusters and regions – with an API contract designed with multi-team collaboration in mind. A service can be exposed as a set of sync or async Nexus operations – the latter provides an operation identifier and a uniform interface to get the status of an operation or its result, receive a completion callback, or cancel the operation.
Temporal uses the Nexus RPC protocol to allow calling across namespace and cluster boundaries. The Go SDK Nexus proposal explains the user experience and shows sequence diagrams from an external perspective.
Read more here on how to enable Nexus and how to operate it here.
2. Workflow Update (public preview)
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 theWorkflowService.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.21 release, the feature was heavily tested and several bug fixes as well as performance optimizations were made.
You can find more information at this link.
3. Host level MutableState cache
The
MutableState
cache has been updated to operate as a host-level cache by default. Previously, this cache was managed at the shard level, with each shard cache holding 512MutableState
entries. Now, the host-level cache, enabled by default (history.enableHostHistoryCache = true
), will be shared across all shards on a given host.The size of the host-level cache is controlled by the
history.hostLevelCacheMaxSize
configuration, which is set to 128,000 entries by default. This change may impact the memory usage of the history service, but it can be adjusted by modifying thehistory.hostLevelCacheMaxSize
value.4. Visibility Enhancement
Enhanced the Nexus CLI to support query filtering for the
schedule list
command. The--query
or-q
(string) option allows filtering of results using a specified list filter.5. Task Queue Statistics
Provide stats for Task Queue backlogs to be used for worker scaling decisions.
User
DescribeTaskQueue
API in enhanced mode (withreport_stats=true
) to get the following info about the Task Queue: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.25.0
)Server With Auto Setup ([what is Auto-Setup?] (https://docs.temporal.io/blog/auto-setup)) (use the tag
1.25.0
)Admin-Tools (use the tag
1.25.0-tctl-1.18.1-cli-1.0.0
)Full Changelog: temporalio/temporal@v1.24.0...v1.25.0
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.
This PR was generated by Mend Renovate. View the repository job log.