Add support for Stand Alone Nexus Operations

[Quinn-With-Two-Ns]

NOTE FOR REVIEWERS: This PR is pending the actual release of the API and Server and will not be merged until those are complete.

Add standalone Nexus operation support

Adds the ability to start, poll, describe, cancel, terminate, list, and count Nexus operations directly from the
client, outside of workflow context. This mirrors the standalone activity pattern and is based on the API we already reviewed the cross SDK design for.

API

• client.NewNexusClient(options) — creates a NexusClient bound to an endpoint+service
• NexusClient.ExecuteOperation(ctx, operation, input, options) — starts an operation and returns a handle
• NexusOperationHandle.GetID() / GetRunID() / Get() / Describe() / Cancel() / Terminate() — handle operations
• client.GetNexusOperationHandle(options) — creates a handle to an existing operation (no network call)
• client.ListNexusOperations(ctx, options) — lists operations via visibility query
• client.CountNexusOperations(ctx, options) — counts operations via visibility query

Interceptor support

Adds 6 methods to ClientOutboundInterceptor: ExecuteNexusOperation, GetNexusOperationHandle, CancelNexusOperation,
TerminateNexusOperation, DescribeNexusOperation, PollNexusOperationResult. List and Count bypass the interceptor,
consistent with standalone activities.

Testing

• Unit tests for interceptor header propagation, client validation, and operation name resolution
• Integration tests covering execute+get, describe, get handle, cancel, terminate, list, count, and validation

---

Note

Medium Risk
Adds new experimental client APIs and interceptor surface for starting/managing Nexus operations, touching core client plumbing and gRPC calls. Risk is mitigated by being additive/experimental, but it expands public interfaces and integration behavior.

Overview
Adds experimental standalone Nexus operation APIs to client.Client, including NewNexusClient, ExecuteOperation, operation handles (Get/Describe/Cancel/Terminate), and visibility helpers ListNexusOperations/CountNexusOperations.

Extends the client interceptor API with Nexus operation hooks (execute/get-handle/poll/describe/cancel/terminate) and implements the underlying gRPC wiring plus option/metadata types in a new internal/internal_nexus_client.go with unit/integration coverage.

Updates CI to disable the new standalone Nexus integration suite by default (DISABLE_STANDALONE_NEXUS_TESTS) and bumps go.temporal.io/api across modules to a newer pre-release commit needed for the new Nexus RPCs.

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

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3fe42e708a

ℹ️ 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".

[chatgpt-codex-connector]

Rename start option field to OperationID for API consistency

ClientStartNexusOperationOptions introduces an ID field while the rest of the new Nexus API uses OperationID (GetNexusOperationHandleOptions, metadata structs, and the integration test callsites). This inconsistency makes normal usage patterns fail at compile time (unknown field OperationID) and effectively breaks the newly added standalone Nexus start API for callers who follow the surrounding API naming. Aligning this field name now avoids shipping an immediately incompatible public surface.

Useful? React with 👍 / 👎.

[Quinn-With-Two-Ns]

This is to be consistent with Stand alone activities naming approach

[cursor]

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

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

[cursor]

Get skips caching result when valuePtr is nil

Medium Severity

In clientNexusOperationHandleImpl.Get, when valuePtr is nil and the poll returns a successful result, the method returns nil without caching the result in h.result. Subsequent calls to Get with a non-nil valuePtr will re-poll the server unnecessarily. The h.result assignment needs to happen before the valuePtr == nil early return, consistent with how the error path always caches before returning.

 

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

[jmaeagle99]

Should the endpoint be deleted at the end of the test? Maybe a deferred deletion?

[jmaeagle99]

Consider adding a test where the run ID is not specified.

[Quinn-With-Two-Ns]

Note this PR is missing support for otel I was planning on addressing that in a separate PR to keep the scope down