chore(deps): bump go.temporal.io/server from 1.24.2 to 1.25.0

dependabot[bot] commented 6 days ago

Bumps go.temporal.io/server from 1.23.0 to 1.26.0.

Release notes

Sourced from go.temporal.io/server's releases.

v1.25.0

Schema changes

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

Core:

MySQL schema v1.14

PostgreSQL schema v1.14

Cassandra schema v1.11

Visibility:

Elasticsearch schema v7

MySQL schema 1.6

PostgreSQL schema v1.6

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 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.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 512 MutableState 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 the history.hostLevelCacheMaxSize value.

... (truncated)

Commits

See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

cloudflare-workers-and-pages[bot] commented 6 days ago

Deploying temporal-operator with Cloudflare Pages

Latest commit:	`99dffad`
Status:	✅ Deploy successful!
Preview URL:	https://dcd43e3f.temporal-operator.pages.dev
Branch Preview URL:	https://dependabot-go-modules-go-tem-wjq2.temporal-operator.pages.dev