SDK Worker Executes activities #1086

Sushisource · 2025-12-30T19:47:16Z

Hook up new activity definitions to execution
Activity invocation now looks like: ctx.activity(MyActivities::my_activity, input, ActivityOptions::default());
Worker now takes Client not Connection
Hash current binary for default build id

Sushisource · 2026-01-06T00:52:31Z

crates/sdk/src/lib.rs

 impl Worker {
-    // /// Create a new worker from an existing connection, and options.
-    // pub fn new(connection: Connection, options: WorkerOptions) -> Self {}
+    // TODO [rust-sdk-branch]: Not 100% sure I like passing runtime here


This is probably my main open question on this PR. This is really only used for telemetry options, and worker heartbeat interval.

We could have worker heartbeat on connection (inside client) as discussed way back, and then only pass in telemetry explicitly... but not sure how worth it that is or not

In other SDKs, we have expected the connection to carry the runtime, the client to carry a connection, and the worker to therefore access the runtime that way upon instantiation. I admit I haven't dug into how one creates a client/connection in this SDK with a runtime, but that's where it should come from IMO.

Currently the connection only needs the metric meter. The whole runtime would have to move into common to have things work that way - but, that's not necessarily an issue. More the problem is that the idea of the runtime in general maybe feels a bit odd in Rust... but maybe that's not a huge issue. It holding onto a tokio runtime/handle is the main odd part. The other thing it holds onto is a tracing subscriber, which actually does make sense.

Is the tracing subscriber not applicable to the client too (and other things on TelemetryInstance)? I think we can find the common above-client/worker things we need and put them in common and have worker instantiation just do what the assume tokio stuff does and not even expose core runtime at all.

But I suspect we may want a concept of an overarching instantiated thing (even if it has a global static default) and that may be a common runtime that carries telemetry stuff (so far, maybe more later). Granted that is different than the "core runtime" which is that + tokio runtime.

Either way we handle it, I would not expect an end user to ever have to import temporalio_sdk_core crate or even know it exists.

cretz

Some notes, didn't do full review, just looking at API design

cretz · 2026-01-06T13:32:17Z

crates/sdk/src/workflow_context.rs

+    pub fn activity<AD: ActivityDefinition>(
+        &self,
+        _activity: AD,
+        input: AD::Input,


What if I have no input? I have seen some tricks done here in Rust for varying arity

It's just (), or (a, b, c) for multi args.

I could generate a bunch of versions of this function for different arities but I kinda hate that and it dirties up the docstrings. They all need different names too since there are no overloads. The tuples feels easier

That you can accept tuples is great, but I am worried about the ambiguity between a single tuple arg and multi args.

They can just serialize to the same thing. No real issue there. The fact that your "single tuple arg" happens to get serialized as multiple args shouldn't matter I don't think.

I think it can matter. There is a big difference between multiple scalar args and a single array of multiple values. I don't think you can even resolve the array ambiguity in some deserialization cases. I think you have to clearly define the difference between single param array and multiple params, and with the latter being rare (only for interop needs IMO), it can probably just be a specialized type.

cretz · 2026-01-06T13:33:14Z

crates/sdk-core/tests/integ_tests/workflow_tests/activities.rs

-    Ok(().into())
+pub(crate) struct SleepyActivities {}
+
+#[activities]


Can you show an example or put it on your TODO to demonstrate how to represent activities implemented in another language? Specifically, can someone have just a trait of activities or something?

you can use the macros on a function whose body is just unimplemented!(), or implement activity definition by hand on your own struct

I can add an example

cretz · 2026-01-06T13:36:36Z

crates/common/src/activity_definition.rs

 /// However, this trait may be implemented manually if desired.
 ///
 /// Implement on a marker struct to define an activity.
 pub trait ActivityDefinition {


I think we should consider making activity definition have an invoke method that can be invoked and allow name to accept self. In (some) other languages, activity definitions can be instantiated by a user, and the decorators/attributes/etc are just sugar for creating them (and so they can be read by a user too). Arguably for those performing untyped activity invocations, they can instantiate a struct that implements this and just provide the name (and the input/output types if they'd like).

That's already the case here. You can just make a struct and implement activity definition. Or, you can use the macros on a function whose body is just unimplemented!() which is cool

Would definitely be interested in a sample/snippet showing how to impl and register activity definition. May be worth a helper struct/fn, though hopefully people don't use that approach to create activities much. I will say one place where we see this approach used a lot in .NET is for DI where they want to control lifetimes and inject deps and such to the invocation.

cretz · 2026-01-06T13:40:57Z

crates/sdk/src/activities.rs

+
+impl ActivityDefinitions {
+    /// Registers all activities on an activity implementer that don't take a receiver.
+    pub fn register_activities_static<AI>(&mut self) -> &mut Self


Is this really that useful? I think it isn't too much to ask all users to put #[activities] be on a struct (even if empty struct) and always require initializing that struct. If some methods (or all) don't happen to take self, that's ok. But it's still the same registration.

Yeah fair point, initializing it would typically be a no-op in that case

cretz · 2026-01-06T13:41:59Z

crates/sdk/src/activities.rs

+        self
+    }
+    /// Registers a specific activitiy that does not take a receiver.
+    pub fn register_activity<AD: ActivityDefinition + ExecutableActivity>(&mut self) -> &mut Self {


If you must keep this approach, I would call this register_activity_static and change register_activity_with_instance to register_activity.

cretz · 2026-01-06T13:47:42Z

crates/sdk/src/lib.rs

One might expect worker stuff to be in workers, same as activity stuff is in activities

cretz · 2026-01-06T13:51:39Z

crates/sdk-core/tests/integ_tests/workflow_tests/activities.rs

+    }
+}
+
+async fn one_activity_wf(ctx: WfContext) -> WorkflowResult<Payload> {


We'll have to come back and fix names like WfContext I think at some point

Yes, we've talked about that a bunch, I haven't forgotten.

cretz · 2026-01-06T13:53:40Z

crates/sdk/src/workflow_context.rs

+    pub fn activity_untyped(
        &self,
+        activity_type: String,
+        input: Payload,


As unfortunate as it is, I think all SDKs have to have some way to both implement and invoke multi-param activities, even if it's not the suggested or typed approach. This is due to needs for dynamic and cross-language compatibility. One way may be a CompositeInput structure that accepts a collection of payloads (and change this to TryInto<Payload> or whatever, because arguably anything that is serializable should be able to be passed here). Arguably you don't even need this separate untyped overload and can allow users to invoke activity with a created-right-then-name-only definition.

Yeah, true, I can potentially just get rid of untyped

cretz · 2026-01-06T13:59:26Z

crates/sdk/src/workflow_context.rs

+    pub fn activity_untyped(
        &self,
+        activity_type: String,
+        input: Payload,


I wonder from a Temporal user POV if we should not be exposing literal prost-generated Payload but instead offer a specific Payload type of our own with any helpers we might want and such. This will also come in handy for people that may want to accept literal Payload which can be preferred in cases of dynamic activities/workflows or just lazy/deferred deserialization.

I think that makes sense but I'm not really going to deal with that until I flesh out the data conversion stuff

cretz · 2026-01-06T14:00:05Z

crates/sdk/src/workflow_context.rs

+    ) -> Result<impl CancellableFuture<ActivityResolution>, PayloadConversionError> {
+        // TODO [rust-sdk-branch]: Get payload converter properly
+        let pc = PayloadConverter::serde_json();
+        let payload = pc.to_payload(&input, &SerializationContext::Workflow)?;


Just noticed this, IMO we should consistently put context parameters first

cretz · 2026-01-06T14:09:43Z

crates/sdk/src/workflow_context.rs


    /// Request to run an activity
-    pub fn activity(
+    pub fn activity<AD: ActivityDefinition>(


Would prefer the verb form of this myself (i.e. start_activity), same for clients starting activities/workflows.

Sushisource added 3 commits December 22, 2025 11:14

Hook up new options

fba10c6

Hooked up definitions to execution

1cbb1d9

Convert all existing activities to new format

4ec0859

Sushisource force-pushed the sdk-worker-improvements branch from 1d870f1 to 6f5266e Compare January 2, 2026 00:36

Massive conversion, compiles but needs test fixes

e374e87

Sushisource force-pushed the sdk-worker-improvements branch from 6f5266e to e374e87 Compare January 2, 2026 02:34

Sushisource added 6 commits January 1, 2026 19:05

Cleanup - but doctests can't pass because of module-in-function issue

e8e4115

Remove core config from integ starter & anyhow from activity error

88451e9

Fix todos in payload conversion errors

853562f

Use client for worker init

2f355b9

Add default build id

ffecc00

Remove unused sdk client-version header setting

0459c62

Sushisource changed the title ~~Sdk worker improvements~~ SDK Worker Executes activities Jan 6, 2026

Change activity invocation to new style

f2da163

Sushisource force-pushed the sdk-worker-improvements branch from f8c693c to f2da163 Compare January 6, 2026 00:44

Sushisource marked this pull request as ready for review January 6, 2026 00:45

Sushisource requested a review from a team as a code owner January 6, 2026 00:45

Sushisource commented Jan 6, 2026

View reviewed changes

cretz reviewed Jan 6, 2026

View reviewed changes

Review comments

3791149

Sushisource force-pushed the sdk-worker-improvements branch from 749e0c6 to 3791149 Compare January 7, 2026 02:00

SDK Worker Executes activities #1086

Are you sure you want to change the base?

SDK Worker Executes activities #1086

Uh oh!

Conversation

Sushisource commented Dec 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cretz Jan 6, 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!

cretz Jan 6, 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!

cretz 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!

cretz Jan 6, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Sushisource Jan 6, 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!

Sushisource Jan 6, 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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

Sushisource commented Dec 30, 2025 •

edited

Loading

cretz Jan 6, 2026 •

edited

Loading

cretz Jan 6, 2026 •

edited

Loading

cretz Jan 6, 2026 •

edited

Loading

Sushisource Jan 6, 2026 •

edited

Loading

Sushisource Jan 6, 2026 •

edited

Loading