Cancellation

There are times where it becomes impossible for a workflow to successfully terminate, or where a condition is met that requires the workflow to stop before it can successfully terminate. The potential causes of a cancellation are enumerated in [CancellationCause][CancellationCause].

When a workflow is cancelled, the caller will never receive a Response message, instead the Outcome will have an Err(_) value. Inside the Err will be a Cancellation to give some information on why the cancellation happened.

There are a few potential causes of cancellation that are worth being mindful of:

• Unreachability - The terminate operation is no longer reachable. You will receive a list of the disposals that happened during the session which led to the unreachability.
• Triggered Cancellation - A cancel operation was explicitly triggered by the workflow itself. You might receive a string that serializes the message that triggered the cancellation from inside the workflow.
• Filtered - The condition of a filtering operation failed to pass, so the workflow was cancelled.

Disposal

When a scope nested inside of another scope gets cancelled, the parent scope will see that as a disposal, meaning the node will simply never yield a final message for that session of the nested scope.

Tip

It is generally discouraged to use cancellation in the happy path of your workflow. The cancellation data received by the caller is meant for debugging purposes, not to be used as regular service output. Instead if your workflow is known to be fallible it should return a Result type.

In crossflow, disposals are something that are managed automatically. Currently there is no operation for users to explicitly react to a disposal, so when the service of a node gets cancelled, this is generally invisible to the parent workflow until it escalates into a cancellation itself. The collect operation can be used to catch unreachability, but there may be significant information lost by the time the workflow reaches that point. Therefore it is best practice to return Result types for fallible workflows instead of having them cancel.