Add Standalone Activities to Temporal Nexus Operation Handler - #2918
Add Standalone Activities to Temporal Nexus Operation Handler#2918Quinn-With-Two-Ns wants to merge 3 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
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
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.
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
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!
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
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.
2 participants
What was changed
Why?
Checklist
Closes
How was this tested:
Note
Medium Risk
Touches Nexus async operation lifecycle, completion callbacks, and activity start RPC wiring; mistakes could affect cross-service operation correlation or cancel behavior, though changes mirror existing workflow-start patterns and are heavily tested.
Overview
Nexus operation handlers can now start standalone activities (not only workflows), returning async
TemporalOperationResultwith activity-execution operation tokens (t:2).TemporalNexusClientgains typed and untypedstartActivityoverloads;TemporalNexusClientImplwires them throughNexusStartActivityHelper, setsNexusOperationMetadata, and routes starts via internalActivityClientInternal.getInvoker().RootActivityClientInvokerapplies the same Nexus semantics as workflow starts: stable request ID, inbound links, on-conflict attach options, completion callbacks (sharedInternalUtils.buildNexusCallback), pre-RPC operation token for callback headers, and response activity links on the Nexus context.TemporalOperationHandlerdispatches cancel on activity tokens (default: cancel viaActivityClienthandle; overridable).OperationToken/OperationTokenUtiladdACTIVITY_EXECUTIONandaid;LinkConverterround-trips activity links.ActivityAlreadyStartedExceptionmaps to NexusBAD_REQUEST. Unit and integration tests cover tokens, links, conflict policies, cancel, and the one-async-operation-per-handler guard.Reviewed by Cursor Bugbot for commit 6d44b43. Bugbot is set up for automated code reviews on this repo. Configure here.