feat(sdk): Add plugins by chris-olszewski · Pull Request #1436 · temporalio/sdk-rust

chris-olszewski · 2026-08-01T16:22:44Z

What was changed

Prefactors

Added Debug implementations to Client/Worker
Moving all interceptors to be registered via WorkerOptions instead of directly on the Worker. Allow multiple WorkerInterceptors per Worker instead of only a single one. This is done in the first commit of the PR.

Main Changes

Added ClientPlugin and WorkerPlugin traits which allows users to implement plugins. The stored types are ErasedClientPlugin and ErasedWorkerPlugin. The worker plugin is just a named Arc<dyn WorkerPlugin>, but ErasedClientPlugin carries WorkerPluginData which is essentially a named Any that carries worker plugins. This is needed since the client crate doesn't have access to the types necessary to define the worker plugin trait. On the actual worker plugin consumption side, we only respect the private PropagatedWorkerPlugin.

Client/worker only plugins will be registered via ClientOptions::client_plugin(plugin: impl ClientPlugin)/WorkerOptions::worker_plugin(plugin: impl WorkerPlugin).

Dual plugins are registered usingClientAndWorkerPlugin struct which enabled propagating plugins that from a Client to any Worker that is constructed with that client. These plugins are used with ClientOptions::plugin. e.g.

struct MyPlugin;
impl ClientPlugin for MyPlugin {..}
impl WorkerPlugin for MyPlugin {..}
let plugin = ClientAndWorkerPlugin::new(MyPlugin);
let client_options = ClientOptions::new("default").plugin(plugin).build();
let client = Client::connect(.., client_options)?;
// Worker will be configured with the worker plugin
let worker = Worker::new(client, ...)?;

Why?

SDK Parity

I do not love the special type for dual plugins, but I didn't find a better solution that didn't encourage misuse.

We could get rid of the special client_plugin/worker_plugin constructors and force users to build the erased types themselves if we want to remove some surface area here. We could offer blanket implementation conversion for any plugin implementers into the erased type, but that opens the door for misuse of dual plugins e.g.

// Will not propagate worker plugins
ClientOptions::new(..).plugin(MyPlugin).build();
// Will propagate worker plugins
ClientOptions::new(..).plugin(ClientAndWorkerPlugin::new(MyPlugin)).build();

Checklist

Closes [Feature Request] Support Plugins #1356
How was this tested:
Added unit tests around error propagation. Very basic integration tests just verifying plugin fields are respected.
Any docs updates needed?
Plugin docs can now be updated to include Rust samples once this is released.

Sushisource · 2026-08-03T17:57:07Z

+    #[builder(field)]
+    worker_plugins: Vec<ErasedWorkerPlugin>,


Does this make sense here? Would it be possible to have a worker plugin add itself to the worker options and infinite loop? 😆

It is private so the only way that a plugin could mess with the list would be to rebuild from scratch via *options = WorkerOptions::new(...).worker_plugins(vec![AnotherPlugin]).build().

Even if a user did that we wouldn't recurse since we take the plugin list before we start applying it. Added a unit test verifying this along with a warning comment.

Well I was less concerned about the infinite loop thing and more just wondering why they actually need to get stored here. Doesn't the plugin apply the options stuff earlier on via the client? Or I guess there's another worker-only path that I probably just didn't quite grok in my review

Yeah, we still allow for worker plugins to be explicitly configured on the worker directly instead of the client. Could force everything through the client and remove this though if that's desired.

Sushisource · 2026-08-03T21:18:55Z

+///
+/// **Experimental:** This API may change or be removed.
+#[derive(Clone)]
+pub struct ClientAndWorkerPlugin {


Yeah I think in theory people could avoid needing to know about this directly by impl

impl From<T> for ClientAndWorkerPlugin where T: ClientPlugin + WorkerPlugin

And then accept anything that Into<ClientAndWorkerPlugin>

Or, maybe better, do

trait ClientAndWorkerPlugin { ... }; impl<T> ClientAndWorkerPlugin for T where T: ClientPlugin + WorkerPlugin {...}

What would the be the trait bounds in the client crate for accepting a ClientAndWorkerPlugin? The trait would need to be defined in the client crate, but the blanket impl needs to be in the SDK so we have access to WorkerPlugin, but won't be able to because of the ophan rule.

We could do this via a trait extension defined in the SDK crate that adds a combined_plugin<ClientPlugin + WorkerPlugin> to client options? Still some concern about user misuse of passing a combined plugin to client_plugin not realizing the woker half of the plugin is getting dropped.

Ah, I see what you mean. Yeah, that being the case I can see why this makes sense.

Sushisource

My last comment isn't blocking. Might be good to have @tconley1428 do a pass.

tconley1428 · 2026-08-05T13:47:13Z

+    ///
+    /// Worker plugin registrations are captured before this method is called. Altering plugins in
+    /// this method does not change which plugins are applied.
+    fn configure_worker_options(&self, _options: &mut WorkerOptions) -> Result<(), PluginError> {


In other languages this also provides a mechanism for running around the worker lifetime

tconley1428 · 2026-08-05T13:49:19Z

+    #[builder(field)]
+    data_converter: Option<DataConverter>,
+    #[builder(field)]
+    client_interceptors: Vec<Arc<dyn ClientInterceptor>>,


I have found separate client/worker interceptor lists to be tricky to use when you have an interceptor which does both (unless that's not a thing in rust) - instead I took both as a single list.

A type could implement both. Hard thing is we would need to add a new enum with each variant having a different Arc<dyn *Interceptor> combination. End users would need to manually construct these as we couldn't provide conversions that would distinguish between types that are implement one interceptor or those that implement multiple.

tconley1428 · 2026-08-05T13:51:01Z

+/// **Experimental:** This API may change or be removed.
+#[derive(Clone, bon::Builder)]
+#[builder(state_mod(vis = "pub"))]
+pub struct SimplePlugin {


This will be more limited than other simple plugins, which allow you to see the previous value before setting using functions. That's especially common around data converter manipulation.

tconley1428 · 2026-08-05T13:53:12Z

    #[builder(field)]
    workflows: WorkflowDefinitions,

+    #[builder(field)]


I don't follow why adding plugins added new interceptor options here. How did worker interceptors work before?

Previously they were registered by modifying an already constructed worker. First commit of this PR switched so all interceptors are set via the WorkerOptions instead of modifying already created workers.

tconley1428 · 2026-08-05T13:55:41Z

+    client_plugin_names: HashSet<String>,
+
+    #[builder(field)]
+    plugins_applied: bool,


What are these things for? They sound like internal state, but this seems like a public configuration object.

Was able to remove the worker one by being a little more careful around the worker lifecycle. Still need the client one as the client in activity context is constructed. This bit of state isn't visible to end users.

tconley1428 · 2026-08-05T13:56:39Z

+/// Use [`ClientAndWorkerPlugin`] for plugins that target both clients and workers.
+///
+/// **Experimental:** This API may change or be removed.
+pub trait WorkerPlugin: Send + Sync + 'static {


Does the rust SDK have a replayer?

chris-olszewski commented Aug 1, 2026

View reviewed changes

Comment thread crates/sdk/src/interceptors.rs

chris-olszewski force-pushed the olszewski/feat_plugins branch from 213835b to 65d811d Compare August 1, 2026 17:07

chris-olszewski marked this pull request as ready for review August 1, 2026 17:08

chris-olszewski requested a review from a team as a code owner August 1, 2026 17:08

Sushisource reviewed Aug 3, 2026

View reviewed changes

chris-olszewski requested a review from Sushisource August 4, 2026 02:41

chris-olszewski force-pushed the olszewski/feat_plugins branch from 91a9469 to 08c3d48 Compare August 4, 2026 12:33

Sushisource approved these changes Aug 4, 2026

View reviewed changes

tconley1428 reviewed Aug 5, 2026

View reviewed changes

chris-olszewski added 14 commits August 5, 2026 22:04

Move interceptor configuration into worker options

b0327a8

Add Rust SDK plugin mechanism

f71aa25

Constrain worker plugin extensions

61341eb

fix client plugin propigation

717f596

remove customizers

aa11252

remove a bunch of experimentals

a404dbb

single worker interceptor

0c1b94b

add changelog

218a7f2

pr feedback: easy ones

75ce26a

pr feedback: recursive plugins

669955b

pr feedback: remove erased worker plugin

d991fc6

pr feedback: hide plugins applied

b70545b

pr feedback: allow simple plugin to take fns

702fbb6

fix rebase

5b1913a

chris-olszewski force-pushed the olszewski/feat_plugins branch from 09ba165 to 5b1913a Compare August 6, 2026 02:16

chris-olszewski enabled auto-merge (squash) August 6, 2026 02:33

chris-olszewski merged commit f192649 into main Aug 6, 2026
22 checks passed

chris-olszewski deleted the olszewski/feat_plugins branch August 6, 2026 02:40

Uh oh!

Conversation

chris-olszewski commented Aug 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What was changed

Prefactors

Main Changes

Why?

Checklist

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Sushisource Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Sushisource left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

chris-olszewski commented Aug 1, 2026 •

edited

Loading

Sushisource Aug 4, 2026 •

edited

Loading