chore(deps): bump go.temporal.io/server from 1.25.2 to 1.26.2

[dependabot]

Bumps go.temporal.io/server from 1.25.2 to 1.26.2.

Release notes

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

v1.26.2

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: temporalio/temporal#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.

... (truncated)

Commits

• 4151e25 Bump Server version to 1.26.2
• d07d0a5 Enable Nexus by default (#7021)
• 7fabbab Fix MultiOperation: unlock terminated WF
• e16204c enable ExecuteMultiOperation (#7007)
• 82d237f Fix a couple of issues in the slog adapter (#7000)
• 8edae6b Fix more merge issues
• f6b8d02 Remove activity tests that could not be cherry picked
• 4ba79a3 Remove TODO from merge conflict
• b8b6cf4 Refresh Nexus endpoints from db periodically (#6997)
• 16db6f0 Handle missing Update acceptedRequest (#6993)
• Additional commits viewable 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 <dependency name> 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)

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}