Skip to content

Conversation

@bergundy
Copy link
Member

@bergundy bergundy commented Jan 12, 2026

What changed?

Add ScheduleToStart and StartToClose timeouts for Nexus operations.

Why?

Give callers more control over timeouts of the various operation lifecycle stages.

Server PR

temporalio/temporal#9010

@bergundy bergundy requested review from a team as code owners January 12, 2026 23:06
Copy link
Member

@cretz cretz left a comment

Choose a reason for hiding this comment

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

I assume like child workflows, none of these timeouts are required

@bergundy
Copy link
Member Author

I assume like child workflows, none of these timeouts are required

See the comment in code:

    // If not set or zero, no start-to-close timeout is enforced.

@bergundy bergundy merged commit d2c3e7c into temporalio:master Jan 13, 2026
4 checks passed
@bergundy bergundy deleted the nexus-caller-timeouts branch January 13, 2026 17:14
bergundy added a commit to temporalio/temporal that referenced this pull request Jan 13, 2026
## Overview

This commit implements two new granular timeout types for Nexus
operations, allowing callers to have fine-grained control over different
phases of operation execution:

- **Schedule-to-Start Timeout**: Maximum time to wait for an operation
to be started (or completed if synchronous) by the handler
- **Start-to-Close Timeout**: Maximum time to wait for an asynchronous
operation to complete after it has been started

These timeouts complement the existing **Schedule-to-Close Timeout** to
provide better control and diagnostics for Nexus operation execution.

See the corresponding API PR:
temporalio/api#695.
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.

4 participants