Add Standalone Activities to Temporal Nexus Operation Handler - #2918
Conversation
| * activity is scheduled from a Nexus operation handler. | ||
| */ | ||
| @Experimental | ||
| final class CompletionCallback { |
There was a problem hiding this comment.
Need to think if this is the right way to propogate this information
aa093f1 to
441ee33
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 441ee33b6c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| activityType, | ||
| args, | ||
| options, | ||
| Header.empty(), |
There was a problem hiding this comment.
Propagate client context headers to Nexus-backed activities
When a Nexus handler starts an activity through this new path, any ContextPropagators configured on the surrounding WorkflowClient are lost because the StartActivityInput is always built with Header.empty(). Standalone ActivityClient.start normally serializes those propagators into the header before reaching the invoker, so callers relying on MDC/tracing/auth context propagation will see backing activities started from Nexus run without that context; build the header from client.getOptions().getContextPropagators() or route through the public ActivityClient.start path instead.
Useful? React with 👍 / 👎.
VegetarianOrc
left a comment
There was a problem hiding this comment.
Looks good to me overall. Just want to make sure we get the token type enum aligned with the other SDKs and to confirm if we want the response link in this PR.
| // TODO: Attach activity-event link when server-side activity link support is available. | ||
| // No StartActivityResponseLink analog exists and there is no verified activity-event link path | ||
| // in LinkConverter. Do NOT copy the synthetic workflow-event link fabrication from | ||
| // NexusStartWorkflowHelper; Nexus operations function correctly without diagnostic links. |
There was a problem hiding this comment.
Should we implement this TODO as part of this PR? The API seems to return the response link: https://github.com/temporalio/api/blob/96d4995096d1589e035104356f6cdd4fa799dc36/temporal/api/workflowservice/v1/request_response.proto#L3257
| // Values 2 and 3 are reserved for future token types (e.g. update-workflow, get-workflow-result). | ||
| ACTIVITY_EXECUTION(4); |
There was a problem hiding this comment.
Activity should be 2 and workflow update should be 3
There was a problem hiding this comment.
Ah yes, fixed!
6eb66fa to
3cb3054
Compare
Compose standalone activity support with the workflow-update Nexus model already present on master. Shared token, callback, link, client, and cancellation paths retain both operation families. Constraint: Preserve the workflow-update token and API contracts from master Rejected: Choose one conflict side | each side would drop a supported Nexus operation family Confidence: high Scope-risk: moderate Reversibility: clean Directive: Keep activity execution at token type 2 and workflow update at token type 3 Tested: Focused temporal-sdk token, link, invoker, client, async activity, and cancellation tests Not-tested: Full repository suite and real-server-only standalone activity cases
3cb3054 to
e3cc170
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
Reviewed by Cursor Bugbot for commit 22ce893. Configure here.

What was changed
Why?
Checklist
Closes
How was this tested:
Note
Medium Risk
Touches Nexus completion callbacks, operation tokens, and activity start RPC wiring; behavior is experimental and relies on server flags, but coverage includes unit and external-service integration tests.
Overview
Nexus operation handlers can now start standalone activities asynchronously (mirroring existing workflow-start support), with completion callbacks, bidirectional links, cancel-by-token, and id-conflict behavior covered by tests.
TemporalNexusClientadds typed and untypedstartActivityoverloads returningTemporalOperationResult.TemporalOperationHandlerdispatches cancel for activity-execution tokens (t:2) and defaults to canceling viaActivityClient.RootActivityClientInvokerapplies Nexus metadata on activity start: NexusrequestId, inbound links, on-conflict attach options, completion callbacks (via sharedInternalUtils.buildNexusCallback), pre-RPC activity operation tokens, and response activity links.ActivityClientInternalexposes the interceptor invoker for Nexus routing.Operation tokens add
ACTIVITY_EXECUTION(t:2) withactivityId/ optionalrunId;LinkConvertersupports activity link URLs. CI bumps Temporal CLI to 1.7.4 and enablesactivity.enableCallbacks.Reviewed by Cursor Bugbot for commit 20a32c4. Bugbot is set up for automated code reviews on this repo. Configure here.