Operations · Guide
You pressed Cancel. Did the AI workflow stop?
Three fictional timelines distinguish stopping browser output, requesting background cancellation and an action that has already completed.
You pressed Cancel. Did the AI workflow stop?
Original AAHouse explanatory video. AI-assisted conceptual visuals and neural narration; original music.
English transcript · Simplified Chinese Mandarin transcript · Taiwan Mandarin transcript · Hong Kong Cantonese transcript · Macao Cantonese transcript
After Cancel, the story is not over
Imagine an AI assistant at a U.S. event-services company preparing customer details and an already authorized confirmation email. An employee notices the wrong date and selects Cancel. This is a fictional drill, not a customer incident. The button expresses intent to stop. A spinner disappearing does not establish that background work stopped. Follow three timelines to examine what cancellation actually means.
Explanatory diagram redrawn from the approved article.
Timeline A: only the browser stopped waiting
MDN describes AbortController as able to abort fetch requests, response-body consumption, and streams.[1] That describes related asynchronous operations, not a promise to reverse a business action. Our design recommendation is to separate stopping incoming output from requesting cancellation of the background job. If a product implements only the former, its button should not imply that an email was prevented.
Explanatory diagram redrawn from the approved article.
Timeline B: cancellation requested, not yet confirmed
Microsoft’s .NET documentation describes cooperative cancellation: listeners notice a request and respond rather than being forcibly terminated.[2] Our recommendation is to retain an intermediate “Cancellation requested” state while the worker reports its outcome at an appropriate checkpoint. Sending a request and confirming that work stopped should not share the same finished label.
Explanatory diagram redrawn from the approved article.
Timeline C: the email was already sent
If sending completed first, show the confirmed sending result honestly. Microsoft’s asynchronous request pattern recommends updating status after the back end handles cancellation and considering partial rollback or compensation.[3] Our recommendation is to inspect the actual receipt before deciding whether a correction is necessary. A correction is a new action; pressing Cancel does not automatically authorize another outgoing message.
Explanatory diagram redrawn from the approved article.
Write a short promise for the button
Specify which job cancellation targets, when stopping remains possible, how completed steps appear, and who handles uncertain outcomes. This is a product agreement, not a universal platform guarantee. After a network interruption, do not translate “No receipt received” into “Canceled successfully,” or immediately submit an identical job again.
Explanatory diagram redrawn from the approved article.
Test three timings, not a disabled button
Use fictional data to test cancellation before start, during execution, and after completion. Compare final backend status, external receipts, and user-visible wording, then test a cancellation request arriving almost simultaneously with completion. This article reports no customer-system testing. The acceptance goal is an explainable outcome, not a claim that every action can be undone.
Explanatory diagram redrawn from the approved article.