Cancelling a Remote A2A Task

Quick answer: The local Stop action ends the desktop view and stops the SSE stream, but it does not cancel a task running on the remote A2A agent. To stop that work, send a CancelTask request with the task reference, then confirm the task moves to a cancelled or terminal state. Never assume the local stop reached the server.

Why a local stop is not enough

A2A tasks run on the remote agent and can take time, and the desktop is a client watching that work. Stopping the local view ends what happens on your machine, but the remote task is a separate process that keeps executing. Closing the SSE stream does not carry a cancellation intent, and the agent has no reason to halt a task it was asked to run.

Treating the two as one action is how orphaned tasks keep running after the client moved on.

Consider a task that runs a long analysis on the remote agent. The user closes the desktop view to move on, and the local stream ends, but the agent keeps the task running and consuming resources. Nothing on the server tells it to stop, because the closed view never sent a message. Hours later the task is still active, holding locks and writing artifacts no one reads. The only way to stop it is to send a CancelTask request with the task reference, then confirm the status. If the user assumes closing the view cancelled it, the orphaned work simply continues unnoticed, which is how these tasks pile up.

The two boundaries

The cancellation request is the only message that tells the remote agent to stop the task.

A careful cancellation sequence

1. Use the local Stop to end the SSE view if you no longer need the stream.
2. Check the task status to see whether it is still running.
3. Send a CancelTask request with the task reference.
4. Confirm the status reaches a cancelled or terminal state.
5. Record the outcome rather than assuming the cancel landed.

Confirming the status matters because a cancel can arrive while the task finishes on its own, and the status tells you which actually happened. It keeps you from asserting a cancellation that did not take effect.

Honest limits

Cancellation does not undo side effects that already completed. A task that wrote a record, sent a message, or changed state before the cancel arrived cannot be rolled back by the request itself. Treat the cancel as a stop against further work rather than a rollback, and verify what already changed.

Streaming and tasks use the SSE viewer, which keeps the progress visible while the task runs. A task that hangs without a defined threshold is easy to forget, so set an expected duration and investigate a run that passes it rather than leaving it open.

After a confirmed cancel, check what the task left behind. Read any artifacts or records it produced before the terminal state, and confirm no downstream process is still waiting on a result that will now never arrive. A cancelled task can leave a half-written record or a pending message that another service depends on, and the cancel itself does not clean those up. Treat the post-cancel check as part of the sequence rather than ending the work the moment the status changes.

Powerduck keeps the local and remote paths distinct so the stop and the cancel are not conflated.

Frequently asked questions

Does Stop cancel the remote task? No. It ends the desktop view and SSE stream, while the remote work needs a CancelTask request.

How do I know the cancel worked? Read the task status and confirm it reaches a cancelled or terminal state.

Does CancelTask undo earlier changes? No. It stops further work, but completed side effects stay in place.

The bottom line

Keep the two boundaries straight: the local Stop ends the desktop view and stream, while the remote A2A task runs until you send a CancelTask request and confirm the status. Cancellation does not roll back completed side effects, and a cancel that races with completion has to be read from the status. Treating the stop as a remote cancel is how orphaned tasks survive. Continue in the A2A guide.