Get from [PyPI](https://pypi.org/project/temporalio/)
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](https://docs.temporal.io/workflows#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.
Specific Changes
2023-08-01 - 393e5c8 - Provide Span.Kind for TracingInterceptor (356)
2023-08-02 - 24fea4c - Expose history size and continue-as-new-suggested (361)
2023-08-02 - 63f63ae - Upgrade grcpio to 1.53.0 (359)
2023-08-07 - 59fbccf - Fix interceptors in testing environment (364)
2023-08-16 - 31358d1 - Add ignore_unknown_fields as an argument to JSONProtoPayloadConverter (365)
2023-08-24 - 40daaaa - Wait for activity completions on worker shutdown (370)
2023-08-31 - aa829d3 - Update core/tonic, update metric options, remove core tracing (380)
2023-09-25 - 3fade95 - Custom metric support (384)
2023-09-28 - d5edb71 - Fix logging of error on activation failure (389)
2023-10-05 - d03f356 - Buffered metrics (391)
2023-10-06 - ded3747 - Encourage threaded activities, warn when max_workers too low, and other small changes (387)
2023-10-09 - 00878ad - Client keep alive support (396)
2023-10-24 - 4242dfb - README updates and CI fixes (403)
2023-10-24 - 97814c2 - Workflow start delay (406)
2023-10-25 - 2c15ed3 - Workflow Update (400)
2023-10-30 - fd938c4 - Update last cleanup items (410)
2023-11-02 - 063b9bf - Update core to get bugfix (411)
2023-11-02 - 7c0a464 - Typed search attributes (366)
2023-11-06 - 4802d2f - Log forwarding support (413)
2023-11-06 - 6dbe2f4 - Fix docstring (414)
2023-11-07 - d6646a2 - Fix pyd file name for Windows (417)