nexus

23 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Synchronous vs asynchronous Nexus Operations use cases

Use a synchronous Nexus Operation only when the complete execution path is highly reliable, has predictably low latency, and finishes well within the 10-second handler deadline. Use an asynchronous Nexus Operation when latency or availability is uncertain, the work might exceed the handler deadline, or execution depends on a potentially unreliable service or database.

Nexus Operation with operation token

Unlike a traditional RPC, an asynchronous Nexus Operation has an operation token that can be used to re-attach to a long-running Operation backed by a Workflow.

Nexus Operation lifecycle spans

An Operation's lifecycle spans scheduling, reliable delivery with retries, handler execution, and result or callback completion.

Synchronous Operation handler deadline

Synchronous Operations must complete within the 10-second handler deadline, as measured from the caller's Nexus Machinery.

Synchronous Operation handler definition

Synchronous handlers are defined using New-Sync-Operation to invoke a Query, Signal, or Update, or execute other reliable code using the Temporal SDK Client.

Asynchronous Operation handler definition

Asynchronous handlers are defined using New-Workflow-Run-Operation to start a Workflow as an asynchronous Operation.

Asynchronous Operation maximum duration

Asynchronous Operations can run up to 60 days, which is the maximum Schedule-to-Close timeout in Temporal Cloud.

Nexus execution semantics at-least-once

The Nexus Machinery provides reliable execution with at-least-once execution semantics for a Nexus Operation, until the caller's Schedule-to-Close timeout is exceeded. The Machinery retries on handler timeouts or retryable errors, so a handler may be invoked multiple times for the same Operation.

Nexus Operation handler idempotency recommendation

Nexus Operation handlers should be idempotent, similar to Activities. Not strictly required in all cases, but highly recommended.

Nexus exactly-once execution semantics

To upgrade to exactly-once execution semantics, back your Operation with a Workflow that uses a WorkflowIDReusePolicy of RejectDuplicates. This allows only one Workflow Execution per Workflow ID within a Namespace for the Retention Period.

Automatic retries for Nexus Operations

Once the caller Workflow schedules an Operation with the caller's Temporal Service, the caller's Nexus Machinery keeps trying to start the Operation. If a retryable Nexus error is returned the Nexus Machinery will retry until the Nexus Operation's Schedule-to-Start timeout or Schedule-to-Close timeout is exceeded.

Schedule-to-Close timeout definition

The Schedule-to-Close timeout limits the total duration from when the Operation is scheduled to when it completes. This is the overall timeout for the entire Operation. The Nexus Machinery automatically retries failed requests internally until this timeout is exceeded, at which point the Operation fails with a NexusOperationTimedOut event. In Temporal Cloud, the maximum Schedule-to-Close timeout is 60 days.

Schedule-to-Start timeout definition

The Schedule-to-Start timeout limits how long the caller is willing to wait for the Operation to be started (or completed, if synchronous) by the handler. If the Operation is not started within this timeout, it fails with TIMEOUT_TYPE_SCHEDULE_TO_START. If not set or set to zero, no Schedule-to-Start timeout is enforced. Requires Temporal Server version 1.31.0 or later.

Start-to-Close timeout definition

The Start-to-Close timeout limits how long the caller is willing to wait for an asynchronous Operation to complete after it has been started. If the Operation does not complete within this timeout after starting, it fails with TIMEOUT_TYPE_START_TO_CLOSE. This timeout only applies to asynchronous Operations. Synchronous Operations ignore this timeout because they complete as part of the start request. If not set or set to zero, no Start-to-Close timeout is enforced. Requires Temporal Server version 1.31.0 or later.

Circuit breaker activation and behavior

Nexus implements circuit breaking per caller-Namespace/Endpoint pair. By default, the circuit breaker activates after 5 consecutive retryable errors. After tripping, the circuit breaker enters the open state and stops sending requests. After 60 seconds, it transitions to half-open, allowing a single probe request. If the probe succeeds, the circuit breaker returns to closed (normal operation). If it fails, the circuit breaker returns to open for another 60 seconds.

Circuit breaker affected by worker availability

Worker availability affects the circuit breaker. If no workers are polling the handler task queue — due to a deployment issue, crash, or scale-down — Nexus requests will time out. Consecutive timeouts count as retryable errors and will trip the circuit breaker just as application-level errors do. Ensure handler workers maintain sufficient availability to avoid unintended circuit breaker trips.

Nexus cancellation propagation

Cancelling a caller Workflow automatically propagates to all pending Nexus Operations and their underlying handler Workflows. A canceled handler Workflow reports a Canceled Failure to the caller.

Nexus termination behavior

Terminating a caller Workflow abandons all pending Nexus Operations. Unlike cancellation, no cancel request is sent to the handler Namespace, so handler Workflows continue running indefinitely, consuming resources until they time out or are manually stopped. Because the handler runs in a separate Namespace, it has no signal that the caller is gone, making orphaned Operations difficult to detect and correlate. If the Nexus Operation was part of a multi-step process, termination also leaves no opportunity to run compensation logic, potentially leaving the system in a partially completed state. Prefer cancellation when possible.

Nexus service versioning approach

Task Routing is the simplest way to version Nexus service code. For backward-incompatible changes, use a different Service name and Task Queue (for example, prod.payments.v2). Callers migrate to the new version on their own deployment schedule.

Multiple Nexus callers attaching to handler Workflow

Operations started with New-Workflow-Run-Operation automatically attach a completion Callback to the handler Workflow. Additional callers can attach to the same handler Workflow using a Conflict-Policy of Use-Existing.

Handler Workflow callback limit

Each handler Workflow has a Callback limit (configurable for self-hosted, see Cloud limits for Temporal Cloud). Callers that exceed the limit receive an error.

Nexus Continue-As-New callback behavior

When a handler Workflow uses Continue-As-New, existing completion Callbacks are copied to the new Execution. The previous Execution's Callbacks remain in Standby state indefinitely.

Synchronous handler repeated failures pitfall

Repeated sync handler failures can trip the circuit breaker, blocking all Operations from that caller to the Endpoint. Use async Operations for long-running work.

Give your agent this brain