Highlights

Typed Search Attributes

Previously, search attributes were untyped dictionaries with string keys and list values. This causes ambiguity on what types a search attribute key represents and leads to errors. Also, the way search attributes were created or upserted allowed mistakes to occur and was not clear to the server exactly what was expected.

Among other classes, temporalio.common.TypedSearchAttributes and temporalio.common.SearchAttributeKey have been added. Search attributes are now best used by creating a global SearchAttributeKey (e.g. SearchAttributeKey.for_int("my-key")) and then referencing that key when getting or mutating search attributes. The TypedSearchAttributes collection (and workflow.typed_search_attributes()) should now be used when creating/accessing search attributes or a warning will emitted. Users should use the keys when accessing the collection or call value_set or value_unset on them to build update objects to pass to temporalio.workflow.upsert_search_attributes when upserting.

Advanced Metrics Support

Previously, metrics were generated and exposed from our Core layer in a way that made them neither reusable nor exportable in a flexible way. We have now both exposed the ability to record metrics via Core and to received buffered metrics from Core.

To record metrics via Core, we have exposed a temporalio.common.MetricMeter via temporalio.activity.metric_meter(), temporalio.workflow.metric_meter(), and temporalio.runtime.Runtime.metric_meter. This meter provides a limited interface to generate metrics. It is not meant to abstract everything one can do with a metric system and users are still encouraged to use their own metrics libraries as needed. The workflow metric meter is built to skip recording meters during replay.

To configure metrics in the SDK, a new runtime must be created with telemetry config. To capture metrics emitted by Core, temporalio.runtime.TelemetryConfig.metrics now accepts a temporalio.runtime.MetricBuffer instance. That same instance must then be used to call retrieve_updates on repeatedly and frequently to get metrics coming out of Core. These come as raw events that can then filtered and/or sent to any other metrics system of choice.

Log Forwarding from Core (experimental)

To configure Core logging in the SDK, a new runtime must be created with telemetry config. Previously, Core logs would be sent to the console which wasn't always desirable. Now, the temporalio.runtime.LoggingConfig.forwarding field can be set with a temporalio.runtime.LogForwardingConfig class which accepts a logging.Logger to send core logs to. This is currently experimental while we gather feedback.

Several Minor Additions

temporalio.workflow.Info.get_current_history_size()added to get history size (get_current_history_length() was already present)
temporalio.workflow.Info.is_continue_as_new_suggested()added to know whether server has suggested to continue as new Client keep alive enabled by default (30s interval, 15s timeout), configurable via keep_alive_config when connecting
Added start_delay to temporalio.client.Client.start_workflow and execute_workflow to support delaying a workflow start
Added experimental support for workflow update which is only available in bleeding edge open source server environments

💥 BREAKING CHANGES

`ScheduleActionStartWorkflow.search_attributes` replaced with `ScheduleActionStartWorkflow.typed_search_attributes`

The rarely used ScheduleActionStartWorkflow.search_attributes has been replaced by ScheduleActionStartWorkflow.typed_search_attributes since that object is used in both directions and we can't determine user intent. Users using the old field name in either direction will see an exception immediately on client side (i.e. no behavior changes or accidental misuse). We also added an untyped_search_attributes field to this class to let untyped ones stay present on update.

Removed `temporalio.runtime.TelemetryConfig.tracing`

temporalio.runtime.TelemetryConfig.tracing and its associated class have been removed. This was not general purpose tracing, this was advanced tracing for debugging internal Core logc only and should not have been used by any users. All user-facing tracing remains untouched.