設想一間美國活動服務公司嘅人工智能助手，整理緊客戶資料，並準備寄出已經批准嘅確認電郵。員工發現日期有錯，撳咗取消。呢個係虛構演練，唔係客戶事故。按鈕可以表達停止嘅意圖，但係唔可以只憑頁面停止轉圈，就證明後台冇繼續執行。我哋沿住三條時間線，檢查佢真正嘅意思。

開發者文件說明，中止控制器可以中止網絡擷取請求、回應正文讀取同串流。呢個講嘅係相關非同步操作，唔係業務回滾承諾。我哋嘅設計建議，係將停止接收輸出，同請求取消後台工作分開：如果產品只做到前者，按鈕文字就唔應該暗示電郵已經被阻止。

微軟嘅點奈特文件，將取消定義為協作過程：監聽者負責發現請求並作出回應，而唔係被強制終止。所以建議保留取消請求已提交呢個中間狀態，畀執行端喺安全檢查點報告結果。發出請求，同工作已經停止，唔可以共用同一個完成標記。

如果寄出電郵先過取消完成，介面應該如實顯示已確認嘅寄送結果。微軟嘅非同步請求模式，建議由後台處理取消之後更新狀態，並且評估部分回滾或者補償操作。我哋建議先核對實際回條，再決定係咪需要更正電郵；更正係新動作，唔可以因為用戶撳咗取消，就自動取得寄送權限。

團隊應該講清楚，取消針對邊項工作、幾時仲可以停止、已完成步驟點樣顯示，同埋結果唔清楚嗰陣由邊個處理。呢個係產品約定，唔係所有平台嘅共同保證。遇到網絡斷線，唔好將冇收到回條改寫成取消成功，亦都唔好即刻重新提交一份相同工作。

建議用虛構資料，分別測試啟動前取消、執行中取消，同完成後取消。核對後台最終狀態、外部回條，同用戶見到嘅文字係咪一致，再測試取消請求同完成通知幾乎同時到達嘅情況。本文冇執行客戶系統測試；驗收目標係令每個結果都解釋得到，唔係承諾任何動作都可以撤銷。