Stop work and recognize abandoned tasks
Integrations can request cancellation of a running agent task, even when another server replica is executing it. Wildo also tracks task liveness so interrupted work can be recognized rather than appearing to run forever.
Stopping work and deciding that a worker disappeared are separate decisions.
Example — Cancel a request that is no longer needed
A partner cancels an agent task after the user changes direction. The stop signal reaches the replica executing that task rather than depending on which replica received the request.
For engineers
Send this body to the A2A endpoint with the task owner’s authorized token:
{
"jsonrpc": "2.0",
"id": 3,
"method": "tasks/cancel",
"params": { "id": "owned-task-id" }
}
The task must belong to the caller’s permitted scope. Cancellation broadcasts the task ID through Redis; the replica holding that task’s local AbortController reacts. This reaches the running model/tool loop instead of merely closing the caller’s text stream.
Keep liveness evidence separate
While executing a turn, its replica refreshes a lease. The mechanism also records that lease establishment succeeded. The abandoned-task sweep considers corroborating evidence before persisting an abandonment verdict: an unreadable lease store is not proof that the worker died.
| Signal | Meaning |
|---|---|
| Live lease | A worker is currently maintaining this task |
| Cancellation request | The authorized caller asks ongoing work to stop |
| Corroborated absence | The sweep has evidence for abandoned execution |
| Redis failure | Liveness or cross-replica cancellation cannot be established normally |
Run the deployment’s Redis and batch infrastructure for the cross-replica and cleanup behavior. Cancellation is cooperative; it does not promise rollback of business operations already completed. Inspect the returned task state and any completed side effects rather than treating a stop request as transactional undo.