Skip to content

Add Temporal Nexus Operation Handler#2842

Open
Quinn-With-Two-Ns wants to merge 11 commits into
temporalio:masterfrom
Quinn-With-Two-Ns:temporal-nexus-operation-handler
Open

Add Temporal Nexus Operation Handler#2842
Quinn-With-Two-Ns wants to merge 11 commits into
temporalio:masterfrom
Quinn-With-Two-Ns:temporal-nexus-operation-handler

Conversation

@Quinn-With-Two-Ns
Copy link
Copy Markdown
Contributor

@Quinn-With-Two-Ns Quinn-With-Two-Ns commented Apr 14, 2026

Add TemporalOperationHandler for generic Nexus operations

Goal

Provide a new base to make it easy to expose more Temporal actions as Nexus Operations

Summary

  • Adds TemporalOperationHandler, a generic OperationHandler implementation that maps Nexus operations to Temporal workflows via a composable StartFunction
  • Adds TemporalNexusClient for starting workflows (typed and untyped) from within Nexus operation handlers
  • Supports subclassing TemporalOperationHandler to customize cancel behavior by overriding cancelWorkflowRun
  • Extracts shared workflow start logic into NexusStartWorkflowHelper, reused by both WorkflowRunOperation and the new handler

Test plan

  • GenericHandlerTypedStartWorkflowTest — typed workflow with return value
  • GenericHandlerTypedProcTest — typed void workflow
  • GenericHandlerUntypedStartWorkflowTest — untyped workflow start
  • GenericHandlerSyncResultTest — synchronous result path
  • GenericHandlerCancelTest — cancel with default and custom behavior

Note

Medium Risk
New experimental handler APIs affect workflow start, cancel, and operation-token parsing on the Nexus server path; refactors are covered by tests but touch operation lifecycle behavior.

Overview
Introduces an experimental TemporalOperationHandler so Nexus operations can be implemented with a composable start callback, TemporalNexusClient (typed/untyped workflow starts), and TemporalOperationResult for sync vs async completion. Cancel paths parse tokens by type and default to canceling the backing workflow, with cancelWorkflowRun overridable on subclasses.

Shared start-workflow + attach Nexus links logic moves into NexusStartWorkflowHelper, which WorkflowRunOperationImpl now uses instead of inlined code. Operation tokens are generalized: WorkflowRunOperationToken becomes OperationToken with explicit type; loadOperationToken supports cancel dispatch without assuming workflow-run type.

Integration tests cover typed/untyped starts, sync results, cancel, and rejecting a second async start per handler invocation.

Reviewed by Cursor Bugbot for commit d6dc34a. Bugbot is set up for automated code reviews on this repo. Configure here.

@Quinn-With-Two-Ns Quinn-With-Two-Ns marked this pull request as ready for review April 14, 2026 22:33
@Quinn-With-Two-Ns Quinn-With-Two-Ns requested a review from a team as a code owner April 14, 2026 22:33
@Quinn-With-Two-Ns Quinn-With-Two-Ns force-pushed the temporal-nexus-operation-handler branch from a33ff01 to 7e61dab Compare May 8, 2026 14:14
Comment thread temporal-sdk/src/main/java/io/temporal/nexus/TemporalNexusClientImpl.java Outdated
@Quinn-With-Two-Ns Quinn-With-Two-Ns force-pushed the temporal-nexus-operation-handler branch from 7e61dab to f2c65fc Compare May 15, 2026 23:04
Comment thread temporal-sdk/src/main/java/io/temporal/nexus/TemporalNexusClientImpl.java Outdated
@bergundy bergundy removed their request for review May 20, 2026 19:14
Copy link
Copy Markdown

@VegetarianOrc VegetarianOrc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great. Couple small questions mostly for my learning!

Comment on lines 34 to +35
if (Strings.isNullOrEmpty(token.getWorkflowId())) {
throw new IllegalArgumentException("Invalid workflow run token: missing workflow ID (wid)");
throw new IllegalArgumentException("Invalid operation token: missing workflow ID (wid)");
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this check be moved into loadWorkflowRunOperationToken?

Comment on lines +63 to +81
/**
* Returns the synchronous result value, or null if this is an async result.
*
* @return the sync result value, or null
*/
@Nullable
public R getSyncResult() {
return syncResult;
}

/**
* Returns the async operation token, or null if this is a sync result.
*
* @return the operation token, or null
*/
@Nullable
public String getAsyncOperationToken() {
return asyncOperationToken;
}
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a style question to familiarize myself with Java a bit more: Should these throw if invoked on the wrong type of result? i.e. should getAsyncOperationToken throw if isSync == true?


public WorkflowRunOperationToken(String namespace, String workflowId) {
this.type = OperationTokenType.WORKFLOW_RUN;
public OperationToken(OperationTokenType type, String namespace, String workflowId) {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With more types of tokens upcoming, should we favor something like static constructors for this like OperationToken.NewWorkflowRunToken() that takes the required fields for the workflow run type?

I guess this is a bit like what OperationTokenUtil provides so feel free to dismiss this!

Copy link
Copy Markdown

@cursor cursor Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

Fix All in Cursor

Reviewed by Cursor Bugbot for commit de643d7. Configure here.

new IllegalStateException(
"Only one async operation can be started per operation handler invocation. "
+ "Use getWorkflowClient() for additional workflow interactions."));
}
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Double-start guard uses wrong error type for implementation error

Low Severity

The asyncOperationStarted guard throws a HandlerException with ErrorType.BAD_REQUEST, but this indicates a handler implementation error (calling startWorkflow twice), not a malformed client request. Using BAD_REQUEST misleads the caller into thinking their request was invalid, when the fault lies in the operation handler's logic. INTERNAL would more accurately represent a handler-side bug.

Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit de643d7. Configure here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants