Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cancelling invocations #56

Closed
wants to merge 4 commits into from
Closed

Cancelling invocations #56

wants to merge 4 commits into from

Conversation

slinkydeveloper
Copy link
Contributor

Fix #52

This text is meant to be open, so that SDKs can choose how to implement the handling of the cancellation signal.
@@ -41,7 +41,8 @@ Depending on the specific syscall, the Restate runtime generates as response eit

Each syscall defines a priori whether it replies with an ack or a completion, or doesn't reply at all.

There are a couple of special message streams for initializing and closing the invocation.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This text was unclear/wrong

@@ -41,7 +41,8 @@ Depending on the specific syscall, the Restate runtime generates as response eit

Each syscall defines a priori whether it replies with an ack or a completion, or doesn't reply at all.

There are a couple of special message streams for initializing and closing the invocation.
Depending on the programming language and/or specific SDK, the SDKs expose a way to await completions using some form of
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This clarification helps understand a bit the rest of the text i believe.

Comment on lines +361 to +379
### Cancelling an invocation

The Restate runtime has a feature to send a signal to "cancel" an invocation, in order to allow the user to eventually
execute operations to revert/compensate its progress.

The idea is that the SDK receives the signal at the beginning of the invocation, surfaces it in the user space and at
the same time records in the journal where it surfaced.

To start the cancellation process, the runtime invokes the SDK with the `StartMessage.cancelled` set to `true`. It's up
to the SDKs to decide how and when to surface the cancellation signal to the user code, be it an exception, or a
saga-like library, or a mix of both. During the handling of the cancellation, the SDK MUST be able to suspend.

The SDK must guarantee that the cancellation signal is fired in the user code deterministically, meaning that on a
subsequent replay of the invocation, e.g. due to a suspension or a network error, the signal should be fired again on
the same point. For this purpose the SDKs can record, when needed, the point where the cancellation signal was fired by
using the `CancelledEntryMessage`.

When the SDK doesn't implement cancellation, the runtime cancellation signal has no effect on the target invocation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Given the SDK has more or less freedom regarding how to implement the cancellation, I kept this text very generic, as from the protocol POV how the sdk exposes the cancellation signal and guarantees its determinism is not important.

Perhaps if we wanna describe these implementation details of the SDKs, we need some other form of text, like SDK features specs or similar.

Copy link
Contributor

@tillrohrmann tillrohrmann left a comment

Choose a reason for hiding this comment

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

Based on the latest discussion about cancellations, I believe that this PR is currently not needed and can be closed.

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.

Cancellations
2 participants