💥 Add explicit Worker configuration for type (workflow/activity/nexus) #1059

yuandrew · 2025-11-13T21:57:42Z

What was changed

Now when registering a worker, users can explicitly specify workflow/nexus/activity workers, instead of always waiting for polls for workflow/nexus workers.

💥 Removed the no_remote_activities in favor of this new WorkerConfig option

Why?

This came up in #1058, to allow for multiple workers with different types to be registered to the same TQ.

This should also simplify shutdown, and make things a little more efficient.

Checklist

Closes
How was this tested:

Added some tests

Any docs updates needed?

Note

Introduce WorkerTaskTypes to selectively enable polling for workflows, activities, and nexus; remove no_remote_activities; update worker behavior, errors, C-bridge, and tests accordingly.

Config/Types:
- Add WorkerTaskTypes (all, workflow_only, activity_only, nexus_only) and replace WorkerConfig.no_remote_activities with task_types.
- Validate at least one task type; ensure max_cached_workflows only when workflows enabled; tighten poller/cache constraints.
Worker Behavior:
- Instantiate pollers/managers conditionally per task_types; workflows/local activities/nexus are optional.
- Adjust shutdown to handle absent components; return ShutDown when polling disabled.
Errors:
- Add WorkflowNotEnabled, ActivityNotEnabled, NexusNotEnabled for inappropriate completions.
C-Bridge:
- Extend worker options with TemporalCoreWorkerTaskTypes; map to core WorkerTaskTypes.
Docs/Comments:
- Update shutdown guidance to reference task_types.
Tests:
- Add comprehensive tests for task type combinations and validation.
- Update existing unit/integration tests to use task_types and new behavior.

^{Written by Cursor Bugbot for commit 5deef19. This will update automatically on new commits. Configure here.}

crates/sdk-core/src/worker/mod.rs

cursor

Bug: Tuner configuration allows conflicting settings.

The validation check for mutual exclusivity between tuner and max_outstanding_* fields doesn't include max_outstanding_nexus_tasks. This allows users to set both a tuner and max_outstanding_nexus_tasks, which should be mutually exclusive like the other max_outstanding_* fields, potentially causing configuration conflicts.

crates/common/src/worker.rs#L354-L362

sdk-core/crates/common/src/worker.rs

Lines 354 to 362 in 07538f4

    
                           return Err( 
        
                               "Legacy build id-based versioning must have a non-empty build_id" 
        
                                   .to_owned(), 
        
                           ); 
        
                       } 
        
                   } 
        
               } 
        
           }

crates/sdk-core/src/test_help/integ_helpers.rs

crates/common/src/worker.rs

crates/sdk-core/src/worker/mod.rs

Sushisource · 2025-11-13T22:58:58Z

crates/sdk-core/src/worker/mod.rs

+                    future::pending::<()>().await;
+                    unreachable!()


If we are in activity-only mode, I think this could hang shutdown. If non_local_activities_complete is set true up at line 867, in the next poll we'll end up inside the pending at 859 and be stuck there forever because local_activities_complete was never set true.

I think we need to set it true in this branch, probably.

At minimum, we should verify that shutting down an activity-only worker works properly.

good catch, added unit and integration tests testing this shutdown

crates/sdk-core/src/worker/mod.rs

cursor

Bug: Configuration conflict bypasses validation.

The validation check for mutual exclusivity between tuner and max_outstanding_* fields doesn't include max_outstanding_nexus_tasks. This allows users to set both a tuner and max_outstanding_nexus_tasks, which violates the documented constraint that these fields are mutually exclusive. The check should include self.max_outstanding_nexus_tasks.is_some() in the condition.

crates/common/src/worker.rs#L369-L373

sdk-core/crates/common/src/worker.rs

Lines 369 to 373 in 85ca74b

    
           { 
        
               return Err("max_outstanding_* fields are mutually exclusive with `tuner`".to_owned()); 
        
           } 
        
           if let Some(wv) = self.versioning_strategy.as_ref() {

cursor · 2025-11-14T01:45:45Z

crates/sdk-core/src/worker/mod.rs

+        if let Some(la_mgr) = &self.local_act_mgr
+            && self
+                .handle_la_complete_action(la_mgr.complete(&task_token, la_res))
+                .is_some()


Bug: Inconsistent Local Activity Error Handling

The complete_local_act function silently succeeds when local_act_mgr is None (workflows disabled), but this is inconsistent with how other task completions are handled. When attempting to complete an activity task with a local activity task token on a worker without workflows enabled, it should return an error like CompleteActivityError::ActivityNotEnabled rather than silently doing nothing, matching the error handling pattern used for regular activities and other task types.

crates/common/src/worker.rs

Sushisource · 2025-11-14T20:00:15Z

crates/sdk-core/tests/integ_tests/worker_tests.rs

+        let worker = starter.get_worker().await;
+


I think we'll want to provide a variant of this test where there is one task of each of the enabled types that gets polled for and completed, just to make sure that once the machinery is active shutdown still works.

Sorry, I know it's a bit annoying but we've got to be super careful with the shutdown stuff.

You can also potentially use rstest to help with the parameterization here

cretz · 2025-11-14T20:58:07Z

crates/sdk-core-c-bridge/src/worker.rs

    pub max_cached_workflows: u32,
    pub tuner: TunerHolder,
-    pub no_remote_activities: bool,
+    pub task_types: u8,


Over the C boundary, I think it's definitely clearer to just use three bools instead of having these magic bitmask integers the SDK will hardcode

Ended up making a struct of bools

cretz · 2025-11-14T20:59:42Z

crates/common/src/worker.rs

+    ///
+    /// Note: At least one task type must be specified or the worker will fail validation.
+    #[builder(default = "worker_task_types::all()")]
+    pub task_types: WorkerTaskTypes,


I figure just three bools is simplest, even if you have to make a hash internally, but I guess not a big deal. Also at this point it could be argued it shouldn't have a default and should be required to be set.

I wanna say having default be all by default matches existing behavior today, but then again not sure it matters much since it's not user facing

No strong opinion on whether we should have a default since every SDK needs to start setting this anyways and the default therefore will never be used if done properly by SDKs

fair point, I can remove the default to force SDKs to be explicit

FWIW, I'm ok w/ defaulted too, just that I hope SDKs will ignore that and always set.

cretz · 2025-11-14T21:01:44Z

crates/common/src/worker.rs

+    ///
+    /// Note: At least one task type must be specified or the worker will fail validation.
+    #[builder(default = "worker_task_types::all()")]
+    pub task_types: WorkerTaskTypes,


Is there somewhere in the client code that has to be altered to properly account for this as part of the worker dedupe check?

Planning on keeping that PR separate, #1059, since that feature introduces different behavior, whereas this PR introduces a new feature, but maintains existing behavior, and to make review easier

cretz

Did not review rest of logic beyond just the lang-facing structure

cretz · 2025-11-17T15:43:14Z

crates/sdk-core-c-bridge/include/temporal-sdk-core-c-bridge.h

  uint32_t max_cached_workflows;
  struct TemporalCoreTunerHolder tuner;
-  bool no_remote_activities;
+  struct TemporalCoreWorkerTaskTypes task_types;


This doesn't need to be a whole separate struct IMO just for the few fields within, but it's mostly harmless

cretz · 2025-11-17T15:44:22Z

crates/common/src/worker.rs

+    ///
+    /// Note: At least one task type must be specified or the worker will fail validation.
+    #[builder(default = "worker_task_types::all()")]
+    pub task_types: WorkerTaskTypes,


No strong opinion on whether we should have a default since every SDK needs to start setting this anyways and the default therefore will never be used if done properly by SDKs

Sushisource · 2025-11-17T19:24:08Z

crates/sdk-core/src/core_tests/workers.rs

+#[case::activity_and_nexus_idle(false, true, true, false, "activity-nexus-idle")]
+#[tokio::test]
+async fn test_task_type_combinations_unified(
+    #[case] enable_workflows: bool,


Could've used #[values] here to have it do the combination matrix for you, but, this is fine.

Add new task_types

7a7eb99

yuandrew requested a review from a team as a code owner November 13, 2025 21:57

cursor bot reviewed Nov 13, 2025

View reviewed changes

crates/sdk-core/src/worker/mod.rs Show resolved Hide resolved

yuandrew changed the title ~~Add explicit Worker configuration for type (workflow/activity/nexus)~~ 💥 Add explicit Worker configuration for type (workflow/activity/nexus) Nov 13, 2025

remove no_remote_activities

07538f4

cursor bot reviewed Nov 13, 2025

View reviewed changes

crates/sdk-core/src/test_help/integ_helpers.rs Outdated Show resolved Hide resolved

crates/common/src/worker.rs Outdated Show resolved Hide resolved

Sushisource reviewed Nov 13, 2025

View reviewed changes

yuandrew added 2 commits November 13, 2025 17:38

Remove use of bitflags

1c94eeb

Missed a change

85ca74b

cursor bot reviewed Nov 14, 2025

View reviewed changes

update temporal-sdk-core-c-bridge.h

9ceb6d8

Sushisource reviewed Nov 14, 2025

View reviewed changes

crates/common/src/worker.rs Outdated Show resolved Hide resolved

Sushisource reviewed Nov 14, 2025

View reviewed changes

cretz reviewed Nov 14, 2025

View reviewed changes

yuandrew added 2 commits November 16, 2025 23:15

Create working test

98b0c9c

Clean up tests

4044f57

cretz approved these changes Nov 17, 2025

View reviewed changes

Remove default from task_types

5deef19

yuandrew merged commit 32cdd90 into temporalio:master Nov 17, 2025
48 of 50 checks passed

Sushisource reviewed Nov 17, 2025

View reviewed changes

cretz mentioned this pull request Nov 17, 2025

Allow activity/workflow/nexus only workers to be registered on the same client/NS/TQ #1058

Merged

	return Err(
	"Legacy build id-based versioning must have a non-empty build_id"
	.to_owned(),
	);
	}
	}
	}
	}

	{
	return Err("max_outstanding_* fields are mutually exclusive with `tuner`".to_owned());
	}

	if let Some(wv) = self.versioning_strategy.as_ref() {

💥 Add explicit Worker configuration for type (workflow/activity/nexus) #1059

💥 Add explicit Worker configuration for type (workflow/activity/nexus) #1059

Uh oh!

Conversation

yuandrew commented Nov 13, 2025 • edited by cursor bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What was changed

Why?

Checklist

Uh oh!

Uh oh!

cursor bot left a comment

Choose a reason for hiding this comment

Bug: Tuner configuration allows conflicting settings.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cursor bot left a comment

Choose a reason for hiding this comment

Bug: Configuration conflict bypasses validation.

Uh oh!

cursor bot Nov 14, 2025

Choose a reason for hiding this comment

Bug: Inconsistent Local Activity Error Handling

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!

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!

cretz left a comment

Choose a reason for hiding this comment

Uh oh!

cretz Nov 17, 2025 • 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

yuandrew commented Nov 13, 2025 •

edited by cursor bot

Loading

cretz Nov 17, 2025 •

edited

Loading