Add support for Stand Alone Nexus Operations

[Quinn-With-Two-Ns]

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/polling/canceling/terminating Nexus operations plus new gRPC/visibility query paths, which could affect client behavior and compatibility with server versions.

Overview
Adds experimental standalone Nexus operations support to the Go SDK client, introducing NewNexusClient and NexusOperationHandle APIs to execute operations outside workflow context, wait for results, describe executions, and issue cancel/terminate requests.

Extends ClientOutboundInterceptor (and base implementations/types) with Nexus operation hooks (ExecuteNexusOperation, PollNexusOperationResult, DescribeNexusOperation, etc.), and implements the underlying gRPC requests plus list/count visibility queries (bypassing interceptors, consistent with standalone activities).

Updates integration/unit tests and mocks to cover the new APIs, bumps the dev-server build config to enable standalone Nexus operation dynamic config, and temporarily disables standalone Nexus integration tests in docker-compose CI.

^{Reviewed by Cursor Bugbot for commit d04b236. 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.}

[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