Skip to content

Conversation

mintlify[bot]
Copy link
Contributor

@mintlify mintlify bot commented Oct 14, 2025

Clarified cancellation requirements, flow, and behavior based on Slack discussion. Added code example showing when cancellation exceptions are thrown at await points.


Created by Mintlify agent

Comment on lines +63 to +65
For cancellation to work, the invocation must reach the deployment (the service endpoint must be reachable).

If the deployment is not reachable, cancellation will not work. In this case, use [kill](#kill) instead.
Copy link
Contributor

Choose a reason for hiding this comment

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

Could be made shorter in a single sentence

Comment on lines +75 to +80
The cancellation exception (`TerminalError` in TypeScript/Python, `TerminalException` in Java/Kotlin) is thrown at the next **await point** - operations that wait for a result:
- Run actions: `ctx.run()`
- Request-response calls
- Sleep
- Awakeable resolution
- Promise combinators (e.g., `RestatePromise.all()`)
Copy link
Contributor

Choose a reason for hiding this comment

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

No need to enumerate them all, as they might change.

Suggested change
The cancellation exception (`TerminalError` in TypeScript/Python, `TerminalException` in Java/Kotlin) is thrown at the next **await point** - operations that wait for a result:
- Run actions: `ctx.run()`
- Request-response calls
- Sleep
- Awakeable resolution
- Promise combinators (e.g., `RestatePromise.all()`)
The cancellation exception (`TerminalError` in TypeScript/Python, `TerminalException` in Java/Kotlin) is thrown at the next **await point** - operations that wait for a result, such as `ctx.run()`, call responses, sleeps, awakeable results, etc.

Comment on lines +82 to +87
Operations that are **not** await points will continue to execute and ignore cancellation:
- Setting and getting state
- Sending messages / one-way calls
- Delayed messages
- Deterministic UUID generation with the context (e.g., `ctx.uuid()`)
- Other non-blocking context operations
Copy link
Contributor

Choose a reason for hiding this comment

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

This one too is too much detailed IMO, plus wrong, get state is an await point. Just remove it.

Suggested change
Operations that are **not** await points will continue to execute and ignore cancellation:
- Setting and getting state
- Sending messages / one-way calls
- Delayed messages
- Deterministic UUID generation with the context (e.g., `ctx.uuid()`)
- Other non-blocking context operations

1. **Propagate to leaves**: Cancellation first reaches the leaves of the call graph
2. **Throw at await points**: Each handler receives the cancellation exception at its next await point
3. **Run compensation**: Handlers execute their compensation logic (if defined)
4. **Propagate upward**: Cancellation flows back up the call graph, allowing each parent to compensate
Copy link
Contributor

Choose a reason for hiding this comment

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

This is not fully right, and I think misleading written this way. The automatic propagation is only to leaves, and not to parents. the cancellation propagates upward if the user rethrows the error manually, or doesn't catch the exception, which btw is correct terminology really only in languages with exceptions/automatic error propagation, it doesn't apply to go and rust for example.

I would be prone to remove this line completely. It's clear enough that it throws an error.

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.

2 participants