Generic Temporal Nexus Operation Handler

[Quinn-With-Two-Ns]

What was changed

Added a generic Nexus operation handler that consolidates the common pattern of "either return a synchronous
result or start a workflow as an async operation."

Why?

The existing WorkflowRun / SyncOperation split forces users to pick the operation shape up front, which is awkward when:

• The start handler decides at runtime whether to respond sync or async.
• The handler needs access to the Temporal client.
• The user wants a custom cancel implementation (e.g. terminate instead of cancel).
• Difficult to extend as we add new operations

The new TemporalOperation unifies these cases behind one API and makes the common path much shorter.

Checklist

1. Closes

2. How was this tested:

3. Any docs updates needed?

---

Note

Medium Risk
Touches experimental Nexus start/cancel and callback/token paths shared with existing workflow-run handlers; behavior is well covered by new tests but affects cross-service operation semantics.

Overview
Introduces TemporalNexusOperationHandler.FromHandleFactory, a single Nexus handler path where the start delegate returns TemporalOperationResult<TResult>—either an immediate value or an async workflow-run token—instead of choosing up front between workflow-run and sync handler shapes.

Handlers receive ITemporalNexusClient / TemporalNexusClient to start workflows (with links, callbacks, request ID, and Nexus-Operation-Token header wiring) or use TemporalClient for sync work like signals. Workflow-start plumbing is centralized in NexusWorkflowStartHelper; WorkflowRunOperationContext now delegates to it. NexusWorkflowRunHandle gains ParseToken, typed OperationToken, and cancel routing by token type with overridable CancelWorkflowRunAsync.

Unit and worker integration tests cover tokens, sync/async results, cancel behavior, links, conflict policy, and no-input overloads.

^{Reviewed by Cursor Bugbot for commit ab83e06. Bugbot is set up for automated code reviews on this repo. Configure here.}

[jmaeagle99]

Still reviewing but wanted to leave my initial comments.

[jmaeagle99]

These methods cannot be overridden because they are not virtual. I would drop this comment.

[jmaeagle99]

If there is some specific concern that derivations of the class will shadow these methods (and callers are not directly invoking these methods via the TemporalNexusOperationHandler class itself), then make them explicit interface implementations e.g. async Task<OperationStartResult<TResult>> IOperationHandler<TInput, TResult>.StartAsync(...)

[jmaeagle99]

If you want to keep it to doc comments, I would suggest adding these to each of the methods instead. They should compose with the inheritdoc, especially since the interface methods do not use <remarks>.

[Quinn-With-Two-Ns]

Ah okay I think I was a bit confused about dotnets behaviour if a user made a subclass

[jmaeagle99]

Rather than these be auto-generated properties, should we stored them in backing fields and have the properties throw an exception if IsSyncResult is not the expected state?

[Quinn-With-Two-Ns]

Sure can do

[jmaeagle99]

The context parameter is not used at all in this default implementation. Is this desired? How does user cancellation flow into the cancel gesture?

[Quinn-With-Two-Ns]

these are run by the worker so users don't cancel these methods and the server doesn't have a way cancel these method either. It is assumed they are fast (<10s)

[cursor]

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

^{Reviewed by Cursor Bugbot for commit 9eb951c. Configure here.}