Add Standalone Activities to Temporal Nexus Operation Handler - #2918
Add Standalone Activities to Temporal Nexus Operation Handler#2918Quinn-With-Two-Ns wants to merge 6 commits into
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!
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 6eb66fa. Configure here.
6eb66fa to
3cb3054
Compare

What was changed
Why?
Checklist
Closes
How was this tested:
Note
Medium Risk
Touches Nexus completion callbacks, operation-token encoding, and activity scheduling RPCs—behavior must stay aligned with workflow-start and other SDKs; large surface area but mostly mirrors an existing pattern with solid test coverage.
Overview
Nexus operation handlers can now start standalone activities asynchronously, parallel to the existing
startWorkflowpath onTemporalNexusClient. Handlers call typed or untypedstartActivityoverloads and get back aTemporalOperationResultwith an activity-execution operation token (ACTIVITY_EXECUTION).RootActivityClientInvokeris wired for Nexus context: it uses the Nexus request ID, attaches inbound links, builds completion callbacks (via sharedInternalUtils.buildNexusCallback), generates a pre-RPC operation token for callback headers, and records response links fromStartActivityExecutionResponse.ActivityClientInternal#getInvoker()lets the Nexus layer route starts through the full activity interceptor chain.Operation tokens gain activity fields (
aid, optionalrid) and typeACTIVITY_EXECUTION; cancel dispatch inTemporalOperationHandleradds defaultcancelActivityExecution(overridable like workflow cancel). Activity links round-trip throughLinkConverter.The same one async operation per handler invocation guard applies to workflow and activity starts. Unit and integration tests cover invoker metadata, tokens, links, double-start, and activity cancel.
Reviewed by Cursor Bugbot for commit 3cb3054. Bugbot is set up for automated code reviews on this repo. Configure here.