Cancel a Workflow - TypeScript SDK
Cancel an Activity from a Workflow
Canceling an Activity from within a Workflow requires that the Activity Execution sends Heartbeats and sets a Heartbeat Timeout. If the Heartbeat is not invoked, the Activity cannot receive a cancellation request. When any non-immediate Activity is executed, the Activity Execution should send Heartbeats and set a Heartbeat Timeout to ensure that the server knows it is still working.
When an Activity is canceled, an error is raised in the Activity at the next available opportunity. If cleanup logic
needs to be performed, it can be done in a finally clause or inside a caught cancel error. However, for the Activity
to appear canceled the exception needs to be re-thrown.
Unlike regular Activities, Local Activities can be canceled if they don't send Heartbeats. Local Activities are handled locally, and all the information needed to handle the cancellation logic is available in the same Worker process.
Set the Activity cancellation type
The cancellationType Activity option decides what the Workflow does when an Activity it is waiting on is cancelled,
whether by a cancellation request against the Workflow Execution or by the
Cancellation Scope the Activity was started in.
ActivityCancellationType.TRY_CANCELis the default. The Workflow asks the Temporal Service to cancel the Activity and the Activity call fails right away with anActivityFailurewhosecauseis aCancelledFailure. The Activity Execution keeps running until its next Heartbeat delivers the cancellation, so Workflow code that continues, for example to run compensation or to retry, can overlap with an Activity that is still executing.ActivityCancellationType.WAIT_CANCELLATION_COMPLETEDasks for the cancellation and keeps the Activity call pending until the Activity Execution has acknowledged it or completed. Use this when the Workflow must not move on while the Activity might still be running. The Activity has to Heartbeat, or the wait lasts until one of its timeouts fires.ActivityCancellationType.ABANDONfails the Activity call right away and does not ask for the cancellation at all. The Activity Execution runs to completion on its own.
import { ActivityCancellationType, proxyActivities } from '@temporalio/workflow';
import type * as activities from './activities';
const { processOrder } = proxyActivities<typeof activities>({
startToCloseTimeout: '10 minutes',
heartbeatTimeout: '30 seconds',
cancellationType: ActivityCancellationType.WAIT_CANCELLATION_COMPLETED,
});
Child Workflows and Nexus Operations have their own cancellation type options, and both of those default to waiting
for the cancellation to complete. See
ActivityOptions.cancellationType
in the API reference for the full definitions.
Reset a Workflow Execution
Resetting a Workflow Execution terminates the current Workflow Execution and starts a new Workflow Execution from a point you specify in its Event History. Use reset when a Workflow is blocked due to a non-deterministic error or other issues that prevent it from completing.
When you reset a Workflow, the Event History up to the reset point is copied to the new Workflow Execution, and the Workflow resumes from that point with the current code. Reset only works if you've fixed the underlying issue, such as removing non-deterministic code. Any progress made after the reset point will be discarded. Provide a reason when resetting, as it will be recorded in the Event History.
- Web UI
- Temporal CLI
- Navigate to the Workflow Execution details page,
- Click the Reset button in the top right dropdown menu,
- Select the Event ID to reset to,
- Provide a reason for the reset,
- Confirm the reset.
The Web UI shows available reset points and creates a link to the new Workflow Execution after the reset completes.
Use the temporal workflow reset command to reset a Workflow Execution:
temporal workflow reset \
--workflow-id <workflow-id> \
--event-id <event-id> \
--reason "Reason for reset"
For example:
temporal workflow reset \
--workflow-id my-background-check \
--event-id 4 \
--reason "Fixed non-deterministic code"
By default, the command resets the latest Workflow Execution in the default Namespace. Use --run-id to reset a
specific run. Use --namespace to specify a different Namespace:
temporal workflow reset \
--workflow-id my-background-check \
--event-id 4 \
--reason "Fixed non-deterministic code" \
--namespace my-namespace \
--tls-cert-path /path/to/cert.pem \
--tls-key-path /path/to/key.pem
Monitor the new Workflow Execution after resetting to ensure it completes successfully.