Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(deps): update temporalio/server docker tag to v1.25.2 #72

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Feb 29, 2024

This PR contains the following updates:

Package Update Change
temporalio/server minor 1.22.1 -> 1.25.2

Release Notes

temporalio/temporal (temporalio/server)

v1.25.2

Compare Source

Release Highlights

This patch release fixes few minor Nexus and Update-with-Start related bugs.

Full Changelog: temporalio/temporal@v1.25.1...v1.25.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.25.2)

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

v1.25.1

Compare Source

Release Highlights

This patch release fixes a couple bugs:

It also adds support for Nexus links.

Full Changelog: temporalio/temporal@v1.25.0...v1.25.1

Helpful links to get you started with Temporal

Temporal Docs
Server
Docker Compose
Helm Chart

Docker images for this release (use the tag 1.25.1)

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

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:

  • 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.

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 (with report_stats=true) to get the following info about the Task Queue:

  • Approximate backlog count
  • Approximate backlog age
  • Approximate rate of adding tasks to the task queue
  • Approximate rate of dispatching tasks from 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

v1.24.3

Compare Source

Release Highlights

This release fixes one bug:

It also fixes a small bug in the Makefile which affects users building from source.

Helpful links to get you started with Temporal

Temporal Docs
Server
Docker Compose
Helm Chart

Docker images for this release (use the tag 1.24.3)

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

Full Changelog: temporalio/temporal@v1.24.2...v1.24.3

v1.24.2

Compare Source

What's Changed

Full Changelog: temporalio/temporal@v1.24.1...v1.24.2

v1.24.1

Compare Source

Schema changes

If you are using SQL based visibility, before upgrading your Temporal Cluster to v1.24.0, you must upgrade your visibility schemas to the following:

  • MySQL schema 1.6
  • PostgreSQL schema v1.6

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

Release Highlights

This release contains schema fix for SQL based visibility introduced in 1.24.0. For full set of new features please check v1.24.0 release notes.

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.24.1)
Server With Auto Setup (what is Auto-Setup?) (use the tag 1.24.1)
Admin-Tools (use the tag 1.24.1-tctl-1.18.1-cli-0.12.0)

Full Changelog: temporalio/temporal@v1.24.0...v1.24.1

v1.24.0

Compare Source

[!CAUTION]
This release introduces a bug in SQL visibility. Please DO NOT use it if you are using SQL-based (PostgreSQL, MySQL, or sqlite) visibility. Elasticsearch based visibility is not affected. Update directly to v1.24.1.

Schema changes

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

  • Core:
    • MySQL schema v1.12
    • PostgreSQL schema v1.12
    • Cassandra schema v1.10
  • Visibility:
    • Elasticsearch schema v7
    • MySQL schema 1.5
    • PostgreSQL schema v1.5

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

Breaking changes
Standard Visibility

As planned, standard visibility is no longer supported in this version. Please, upgrade to advanced visibility as well as the config keys to setup visibility before upgrading to this version. Refer to v1.20.0 release notes for upgrade instructions, and also check the v1.21.0 release notes for config key changes.

Note that you also need to update the plugin name for the main store, ie., if you are using mysql plugin name for the main store, then you need to change to mysql8. Similarly, if it's postgres, then change it to postgres12.

Deprecation Announcements
Worker Versioning APIs [Experimental]

The following changes were made to Worker Versioning APIs:

  • Deprecated UpdateWorkerBuildIdCompatibility in favor of the new  UpdateWorkerVersioningRules API.
  • Deprecated GetWorkerBuildIdCompatibility in favor of the new GetWorkerVersioningRules API.
  • Deprecated GetWorkerTaskReachability in favor of DescribeTaskQueue enhanced mode (api_mode=ENHANCED)

Together with the old APIs, the Version Set concept is also deprecated and replaced with “versioning rules” which are more powerful and flexible. More details can be found in https://github.com/temporalio/api/blob/master/temporal/api/taskqueue/v1/message.proto#L153.

For using these experimental APIs you need to enable the following configs:

  • frontend.workerVersioningRuleAPIs
  • frontend.workerVersioningWorkflowAPIs
Release Highlights
Namespace Burst Ratio

Removing frontend.namespaceBurst and adding frontend.namespaceBurstRatio config. Similarly replacing frontend.namespaceBurst.visibility and frontend.namespaceBurst.namespaceReplicationInducingAPIs with frontend.namespaceBurstRatio.visibility and frontend.namespaceBurstRatio.namespaceReplicationInducingAPIs.

The old values are used to specify the burst rate as number of requests per second. New values will specify burst as a ratio of their respective RPS limit. This ratio will be applied to calculated RPS limit from global and per-instance rate limits.

Visibility: Parent workflow execution

We added two new system search attributes: RootWorkflowId and RootRunId. If you have previously created custom search attributes with one of these names, attempts to set them will start to fail. We suggest updating your workflows to not set those search attributes, delete those search attributes and then upgrade Temporal to this version. Alternatively, you can also set the dynamic config system.supressErrorSetSystemSearchAttribute: true. When this dynamic config is set to true, your workflow will not fail when trying to set a value on a system search attribute, and it will ignore your input for those system search attributes.

OpenAPI HTTP API Documentation

OpenAPI v2 docs are served at /api/v1/swagger.json while v3 is at /api/v1/openapi.yaml when our HTTP API is enabled.

Shard Info Update Optimizations

Operators can now configure how often we update shard info (tracking how many tasks have been acked, etc). This improves recovery speed by persisting shard data more frequently.

This can be configured through the following dynamic config values:

  • history.shardUpdateMinTasksCompleted - the minimum number of tasks which must be completed (across all queues) before the shard info can be updated
  • history.shardUpdateMinInterval - the minimum amount of time between shard info updates unless shardUpdateMinTasksCompleted tasks have been acked

Note that once history.shardUpdateMinInterval amount of time has passed we'll update the shard info regardless of the number of tasks completed

Interpolate MySQL query parameters by default (#​5428)

We now interpolate parameters into queries client-side for MySQL main databases but not visibility.

When interpolateParams is false (the default) the driver will prepare parameterized statements before executing them, meaning we need two round-trips to the database for each query. By setting interpolateParams to true the DB driver will handle interpolation and send the query just once to the database, halving the number of round trips necessary. This should improve the performance of all Temporal deploys using MySQL.

OpenTelemetry env variables

Support for enabling OpenTelemetry for tracing gRPC requests via environment variables. See develop/docs/tracing.md for details.

Matching task queue handover

Various improvements were made to task queue handover when adding/removing/restarting matching nodes. This should improve tail latency for task dispatch during those situations. To enable the improvements, operators should set the dynamic config matching.alignMembershipChange to a value like 10s after fully deploying v1.24 to the entire cluster. This may become the default in future versions.

UTF-8 validation in protobuf messages

When we migrated Temporal from the deprecated gogoproto fork of Google’s protobuf library to the official version in v1.23, we disabled protobuf’s default utf-8 validation to ensure a smooth deployment, since gogoproto did not validate fields for utf-8, and turning on validation immediately would have broken applications that accidentally used invalid utf-8.

This was a temporary measure and we will eventually re-enable validation. As the first step, we’ve added tools to detect and warn about invalid utf-8 without breaking applications. There are two sets of dynamic config settings to use.

The sample settings are set to a floating point value between 0.0 and 1.0 (default 0.0), and control what proportion of either RPC requests, responses, or data read from persistence, is validated for utf-8 in strings. If invalid utf-8 is found, warnings will be sent to logs, and the counter metric utf8_validation_errors will be incremented.

The fail settings (boolean, default false) control whether a validation error will be turned into a RPC failure or data corruption error.

  • system.validateUTF8.sample.rpcRequest
  • system.validateUTF8.sample.rpcResponse
  • system.validateUTF8.sample.persistence
  • system.validateUTF8.fail.rpcRequest
  • system.validateUTF8.fail.rpcResponse
  • system.validateUTF8.fail.persistence

If you think your application may be using invalid utf-8, we suggesting turning on the sample settings without the fail settings and running for a while. In a future version, validation and errors will be turned on by default (effectively sample set to 1.0 and fail set to true).

admin-tools docker image versioning

We separated admin-tools docker image release process. Version tag now includes versions of tctl (deprecated but still supported CLI) and temporal (modern CLI) binaries. This image is released every time whenever new version of any of these component is released. Current latest tag is 1.24.0-tctl-1.18.1-cli-0.12.0.

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.24.0)
Server With Auto Setup (what is Auto-Setup?) (use the tag 1.24.0)
Admin-Tools (use the tag 1.24.0-tctl-1.18.1-cli-0.12.0)

Full Changelog: temporalio/temporal@v1.23.1...v1.24.0

v1.23.1

Compare Source

Release Highlights
  • Dependencies version upgrade for addressing security vulnerabilities
  • Bug fixes for Schedule and replication
All Changes

2024-04-30 - fad6bdc - Bump Server version to 1.23.1
2024-04-26 - 99b6e0c - Fix schedule workflow to CAN after signals (#​5799)
2024-04-26 - 1bb03b7 - Update dependencies (#​5789)
2024-04-26 - 9701ef0 - Recalculate schedule times from previous action on update (#​5381)
2024-04-26 - dd4323a - Handle data corruption in history resend (#​5398)
2024-04-26 - 9b1981c - Do schedule backfills incrementally (#​5344)
2024-04-26 - a520df2 - Use proto encoding for scheduler workflow next time cache (#​5277)

Helpful links to get you started with Temporal

Temporal Docs
Server
Docker Compose
Helm Chart

Docker images for this release (use the tag 1.23.1)

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

Full Changelog: temporalio/temporal@v1.23.0...v1.23.1

v1.23.0

Compare Source

Release Highlights

Breaking Changes

github.com/gogo/protobuf has been replaced with google.golang.org/protobuf

We've fully replaced the use of gogo/protobuf with the official google protobuf runtime. This has both developmental and operational impacts as prior to Server version v1.23.0 our protobuf code generator allowed invalid UTF-8 data to be stored as proto strings. This isn't allowed by the proto3 spec, so if you're running a custom-built temporal server and think some tenant may store arbitrary binary data in our strings you should set -tags protolegacy when compiling the server. If you use our Makefile this is already done.

If you don't and see an error like grpc: error unmarshalling request: string field contains invalid UTF-8 then you will need to enable this when building the server. If you're unsure then you should specify it anyways as there's no harm in doing so unless you relied on the protobuf compiler to ensure all strings were valid UTF-8.

Developers using our protobuf-generated code will notice that:

  • time.Time in proto structs will now be [timestamppb.Timestamp](https://pkg.go.dev/google.golang.org/[email protected]/types/known/timestamppb#section-documentation)
  • time.Duration will now be [durationpb.Duration](https://pkg.go.dev/google.golang.org/protobuf/types/known/durationpb)
  • V2-generated structs embed locks, so you cannot dereference them.
  • Proto enums will, when formatted to JSON, now be in SCREAMING_SNAKE_CASE rather than PascalCase.
    • If trying to deserialize old JSON with PascalCase to proto use [go.temporal.io/api/temporalproto](https://pkg.go.dev/go.temporal.io/api/temporalproto)
  • google/protobuf objects, or objects embedding these protos, cannot be compared using reflect.DeepEqual or anything that uses it. This includes testify and mock equality testers!
    • If you need reflect.DeepEqual for any reason you can use go.temporal.io/api/temporalproto.DeepEqual instead
    • If you need testify require/assert compatible checkers you can use the go.temporal.io/server/common/testing/protorequire, go.temporal.io/server/common/testing/protoassert packages
    • If you need matchers for gomock we have a helper under go.temporal.io/server/common/testing/protomock

New System Search Attributes

We added two new system search attributes: ParentWorkflowId and ParentRunId. If you have previously created custom search attributes with one of these names, attempts to set them will start to fail. We suggest updating your workflows to not set those search attributes, delete those search attributes and then upgrade Temporal to this version.

Alternatively, you can also set the dynamic config system.supressErrorSetSystemSearchAttribute to true. When this dynamic config is set values for system search attributes will be ignored instead of causing your workflow to fail. Please use this as temporary workaround, because it could hide real issue in users workflows.

Schema changes

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

  • Core:
    • MySQL schema v1.11
    • PostgreSQL schema v1.11
    • Cassandra schema v1.9
  • Visibility:
    • Elasticsearch schema v6
    • MySQL schema 1.4
    • PostgreSQL schema v1.4

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

Deprecation Announcements
  • We've replaced all individual metrics describing Commands (e.g. complete_workflow_command, continue_as_new_command etc.) with a single metric called command which has a tag “commandType” describing the specific command type (see https://github.com/temporalio/temporal/pull/4995)
  • Standard visibility will be deprecated in the next release v1.24.0 along with old config key names, i.e. this is the last minor version to support them. Please refer to v1.20.0 release notes for upgrade instructions, and also refer to v1.21.0 release notes for config key changes.
  • In advanced visibility, the LIKE operator will no longer be supported in v1.24.0. It never did what it was meant to do, and only added confusing behavior when used with Elasticsearch.
Golang version
  • Upgraded golang to 1.21
Batch workflow reset by Build ID

For situations where an operator wants to handle a bad deployment using workflow
reset, the batch reset operation can now reset to before the first workflow task
processed by a specific build id. This is based on reset points that are created
when build id changes between workflow tasks. Note that this also applies across
continue-as-new.

This operation is not currently supported by a released version of the CLI, but
you can use it through the gRPC API directly, e.g. using the Go SDK:

client.WorkflowService().StartBatchOperationRequest(ctx, &workflowservice.StartBatchOperationRequest{
	JobId:           uuid.New(),
	Namespace:       "my-namespace",
	// Select workflows that were touched by a specific build id:
	VisibilityQuery: fmt.Sprintf(`BuildIds = "unversioned:bad-build"`),
	Reason:          "reset bad build",
	Operation: &workflowservice.StartBatchOperationRequest_ResetOperation{
		ResetOperation: &batch.BatchOperationReset{
			Identity: "bad build resetter",
			Options: &commonpb.ResetOptions{
				Target: &commonpb.ResetOptions_BuildId{
					BuildId: "bad-build",
				},
				ResetReapplyType: enumspb.RESET_REAPPLY_TYPE_SIGNAL,
			},
		},
	},
})
History Task DLQ

We've added a DLQ to history service to handle poison pills in transfer / timer queues and other history task queues including visibility and replication queues. You can see our operators guide for more details.

If you want tasks experiencing unexpected errors to go to the DLQ after a certain number of failures you can set the history.TaskDLQUnexpectedErrorAttempts dynamic config.

Approximately FIFO Task Queueing

Once this feature is enabled, our task queues will be roughly FIFO.

This is disabled by default in 1.23, as we continue testing it but expect that it’ll be enabled by default in 1.24. To enable it the following config should be set to a short duration (e.g. 5sec) from its current default value (10yrs): "matching.backlogNegligibleAge"

We've added the following metrics as part of this effort:

  • poll_latency - this is a per-task-queue histogram of the duration between worker poll request and response (with or without task) calculated from the Matching server’s perspective
  • task_dispatch_latency - this is a histogram of schedule_to_start time from Matching's perspective, broken down by task queue and task source (backlog vs history)
Global Persistence Rate Limiting

We've added the ability to specify global (cluster level) rate limiting value for the persistence layer. You can configure by specifying the following dynamic config values:

  • frontend.persistenceGlobalMaxQPS
  • history.persistenceGlobalMaxQPS
  • matching.persistenceGlobalMaxQPS
  • worker.persistenceGlobalMaxQPS

You can also specify this on the per-namespace level using

  • frontend.persistenceGlobalNamespaceMaxQPS
  • history.persistenceGlobalNamespaceMaxQPS
  • matching.persistenceGlobalNamespaceMaxQPS
  • worker.persistenceGlobalNamespaceMaxQPS

Please be aware that this functionality is experimental. This global rate limiting isn’t workload aware but shard-aware; we currently allocate this QPS to each pod based on the number of shards they own rather than the demands of the workload, so pods with many low-workload shards will have a higher allocation of this limit than pods with fewer but more active workloads. If you plan to use this you will want to set the QPS value with some headroom (like 25%) to account for this.

Renamed Deadlock-detector metrics

The metrics exported by the deadlock detector were renamed to use a dd_ prefix to avoid confusion with other lock latency metrics. Affected metrics: dd_cluster_metadata_lock_latency, dd_cluster_metadata_callback_lock_latency, dd_shard_controller_lock_latency, dd_shard_lock_latency, dd_namespace_registry_lock_latency.

Visibility Prefix Search

Visibility API now supports prefix search by using the keyword STARTS_WITH. Eg: WorkflowType STARTS_WITH 'hello_world'. Check the Visibility documentation for additional information on supported operators.

Helpful links to get you started with Temporal

Temporal Docs
Server
Docker Compose
Helm Chart

Docker images for this release (use tag v1.23.0)

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

New Contributors

Full Changelog: temporalio/temporal@v1.22.6...v1.23.0

v1.22.7

Compare Source

Release Highlights

This release mitigates a problem where invalid UTF-8 data could be supplied to the history service, causing a denial of service

Helpful links to get you started with Temporal

Temporal Docs
Server
Docker Compose
Helm Chart

Docker images for this release (use the tag 1.22.7)

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

Full Changelog: temporalio/temporal@v1.22.6...v1.22.7

v1.22.6

Compare Source

Release Highlights

This release mitigates a rollback problem introduced into one of our v1.23.0 release candidates. This has no impact on OSS users using official releases.

All Changes

2024-02-29 - 2899920 - Bump Server version to 1.22.6
2024-02-29 - 1eba091 - Update Go SDK to handle SDKPriorityUpdateHandling flag (#​5468)

Helpful links to get you started with Temporal

Temporal Docs
Server
Docker Compose
Helm Chart

Docker images for this release (use the tag 1.22.6)

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

v1.22.5

Compare Source

All Changes

2024-02-22 - 2787da3 - Bump Server version to 1.22.5
2024-02-22 - 760ea9c - Bump Server version to 1.22.5-rc2
2024-02-21 - 2ea05b3 - Ensure PollActivityTaskQueueResponse.ScheduleToCloseTimeout is not nil (#​5444)
2024-02-02 - d4f38c2 - Bump Server version to 1.22.5-rc1
2024-02-01 - 64fe53c - Backport code to drop internal errors encountered during task processing (#​5385)
2024-01-31 - 2647b36 - Fix scheduled task rescheduling on failover (#​5377)

Helpful links to get you started with Temporal

Temporal Docs
Server
Docker Compose
Helm Chart

Docker images for this release (use the tag 1.22.5)

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

v1.22.4

Compare Source

All Changes

2024-01-12 - fb61704 - Bump Server version to 1.22.4
2024-01-12 - f2659e7 - Change auth order (#​5294)
2024-01-12 - 4489f17 - Fix buildkite cassandra setup (#​5263)
2024-01-08 - 6dcab73 - Update GHA setup-go to pull version from go.mod file (#​5207)

Helpful links to get you started with Temporal

Temporal Docs
Server
Docker Compose
Helm Chart

Docker images for this release (use the tag 1.22.4)

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

v1.22.3

Compare Source

Important

The dependency golang.org/x/net was updated to address CVE-2023-39325, CVE-2023-3978, CVE-2023-44487.

All Changes

2023-12-07 - 4eca060 - Bump Server version to 1.22.3
2023-11-30 - 407ff8a - Fix nil panic (#​5153)
2023-11-30 - db10079 - Activate changes in #​4990 and #​5034 (#​5035)
2023-11-30 - 20a4829 - Always set RPS on dynamic rate limiter refresh (#​5180)
2023-11-30 - 79bacb9 - Fix default persistence request priority (#​5177)
2023-11-30 - b4b6581 - Update force replication with low priority context (#​5010)
2023-11-27 - 294e8a3 - 1.22.3 build fix for cherry pick build error (#​5163)
2023-11-22 - 38f0eb2 - Fix set up search attributes in secondary SQL visibility (#​5143)
2023-11-20 - 1f04629 - Add more logging message to monitor branch token update (#​5058)
2023-11-20 - 6ba388c - Handle branch token update with long poll API (#​4943)
2023-11-20 - 98b5700 - golang.org/x/net: update to address CVE-2023-39325, CVE-2023-3978, CV… (#​5011)

Helpful links to get you started with Temporal

Temporal Docs
Server
Docker Compose
Helm Chart

Docker images for this release (use the tag 1.22.3)

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

v1.22.2

Compare Source

All Changes

2023-11-13 - db23e86 - Add action metrics for schedule and updates (#​5101)
2023-11-03 - 37da275 - Allow list of keywords in dual visibility setting (#​5065)
2023-11-01 - 26114d7 - Hopefully avoid panic in DescribeWorkflowExecution (#​5057)
2023-10-31 - ddf9799 - Bump server version to 1.22.2 (#​5056)
2023-10-31 - ef3b92b - Fix schedule workflow unit test (#​5052)
2023-10-30 - 2320fc1 - Add force-continue-as-new signal to schedule workflow (#​5034)
2023-10-30 - b8163ce - Use ContinueAsNewSuggested in scheduler workflow (#​4990)
2023-10-30 - 88f8f11 - Update Go SDK to v1.25.1 (#​4955)
2023-10-30 - cba2ce7 - Improve scheduler workflow unit test (#​4962)
2023-10-30 - 53a4979 - Expose buffer size and # dropped actions in ScheduleInfo (#​4839)
2023-10-30 - 0fc50f8 - Adjust action metrics (#​5043)
2023-10-30 - 91425ba - Emit action metrics for batch of markers (#​4905)
2023-10-30 - f442eb7 - Validate search attributes values in queries to ES (#​5036)
2023-10-30 - 19ba0ce - Disable eager activities for incompatible versioned activities (#​5030)
2023-10-30 - cd14e15 - Add refresh task for close workflow (#​4999)
2023-10-30 - e022877 - Refresh upsert visibility task only for running workflows (#​4909)
2023-10-30 - f99bd88 - Lock get current execution for API requests (#​4970)
2023-10-30 - 8dc833c - Fix GenerateMigrationTasks behavior (#​4987)
2023-10-30 - 1a30833 - Return InvalidArgument error when we get HTTP 400 from elasticsearch (#​4900)
2023-10-30 - b6c9868 - Reuse cached RemoteAdminClient in VerifyReplicationTasks (#​4997) (#​5050)


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 is behind base branch, 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 was generated by Mend Renovate. View the repository job log.

@renovate renovate bot changed the title chore(deps): update temporalio/server docker tag to v1.22.5 chore(deps): update temporalio/server docker tag to v1.22.6 Mar 1, 2024
@renovate renovate bot force-pushed the renovate/temporalio-server-1.x branch from cf5c0ab to 0a692bc Compare March 1, 2024 08:44
@renovate renovate bot force-pushed the renovate/temporalio-server-1.x branch from 0a692bc to 54a4c96 Compare March 23, 2024 17:39
@renovate renovate bot changed the title chore(deps): update temporalio/server docker tag to v1.22.6 chore(deps): update temporalio/server docker tag to v1.23.0 Mar 23, 2024
@renovate renovate bot force-pushed the renovate/temporalio-server-1.x branch 2 times, most recently from adae819 to 8a55c6a Compare April 4, 2024 15:31
@renovate renovate bot force-pushed the renovate/temporalio-server-1.x branch 2 times, most recently from aa0ab6b to ff26a34 Compare April 23, 2024 03:58
@renovate renovate bot changed the title chore(deps): update temporalio/server docker tag to v1.23.0 chore(deps): update temporalio/server docker tag to v1.23.1 May 1, 2024
@renovate renovate bot force-pushed the renovate/temporalio-server-1.x branch from ff26a34 to 1c61f7e Compare May 1, 2024 05:39
@renovate renovate bot force-pushed the renovate/temporalio-server-1.x branch from 1c61f7e to 339473e Compare June 1, 2024 08:39
@renovate renovate bot changed the title chore(deps): update temporalio/server docker tag to v1.23.1 chore(deps): update temporalio/server docker tag to v1.24.0 Jun 1, 2024
@renovate renovate bot force-pushed the renovate/temporalio-server-1.x branch 3 times, most recently from 04e723b to cdeee58 Compare June 6, 2024 08:50
@renovate renovate bot changed the title chore(deps): update temporalio/server docker tag to v1.24.0 chore(deps): update temporalio/server docker tag to v1.24.1 Jun 6, 2024
@renovate renovate bot force-pushed the renovate/temporalio-server-1.x branch 2 times, most recently from 49c02d0 to bc2ff9d Compare June 19, 2024 17:50
@renovate renovate bot changed the title chore(deps): update temporalio/server docker tag to v1.24.1 chore(deps): update temporalio/server docker tag to v1.24.2 Jun 19, 2024
@renovate renovate bot force-pushed the renovate/temporalio-server-1.x branch 2 times, most recently from e90488c to 0e75144 Compare August 20, 2024 14:00
@renovate renovate bot force-pushed the renovate/temporalio-server-1.x branch from 0e75144 to b8b79fd Compare September 7, 2024 08:59
@renovate renovate bot changed the title chore(deps): update temporalio/server docker tag to v1.24.2 chore(deps): update temporalio/server docker tag to v1.25.0 Sep 7, 2024
@renovate renovate bot force-pushed the renovate/temporalio-server-1.x branch 2 times, most recently from 1043765 to e77bbdb Compare September 11, 2024 15:48
@renovate renovate bot force-pushed the renovate/temporalio-server-1.x branch from e77bbdb to 2437772 Compare October 12, 2024 02:47
@renovate renovate bot changed the title chore(deps): update temporalio/server docker tag to v1.25.0 chore(deps): update temporalio/server docker tag to v1.25.1 Oct 12, 2024
@renovate renovate bot force-pushed the renovate/temporalio-server-1.x branch 3 times, most recently from 707c9d5 to 62317e1 Compare November 4, 2024 17:09
@renovate renovate bot force-pushed the renovate/temporalio-server-1.x branch from 62317e1 to 5456f9d Compare November 8, 2024 02:33
@renovate renovate bot changed the title chore(deps): update temporalio/server docker tag to v1.25.1 chore(deps): update temporalio/server docker tag to v1.25.2 Nov 8, 2024
@renovate renovate bot force-pushed the renovate/temporalio-server-1.x branch from 5456f9d to 219a101 Compare November 14, 2024 00:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants