昨天談到批次重新處理訂單時，需要核對庫存服務的容量。假設團隊評估後，決定讓批次工作先排隊，再以受控的速率處理，營運人員稍後查看逐筆結果。

流程看起來很完整：勾選、送出、排隊、處理、顯示結果。但接手實作時，還有一個值得確認的問題：勾選當下符合處理條件的訂單，輪到它執行時，還符合嗎？

排進佇列的時候，世界沒有跟著暫停

假設一筆訂單已經查明庫存未扣減，依現有規則允許補送。營運人員在後台勾選它，送出批次工作。

但在這筆工作真正執行前，另一位同事已經透過單筆功能完成處理。原本那筆批次工作接著被取出，如果直接拿提交時的資料呼叫庫存服務，就可能再次送出同一筆扣減。

「只有符合條件的訂單才能重新處理」可能早就寫在文件裡，但實作時，我們把它理解成「送出時檢查一次就好」。這背後藏著一個假設：從檢查到執行之間，不會有人改變這筆訂單的狀態。

畫面把按鈕反灰，只能限制那個畫面上的操作，無法保證另一位使用者或背景工作不會處理同一筆資料。選擇排隊之後，「何時檢查」才成為需要確認的實作細節。

從流程裡找出「我們以為不會發生」的事

我會先沿著既有程式追查：除了這次新增的批次功能，單筆按鈕、背景作業或其他入口，是否也會處理這筆訂單？接著聚焦在等待期間會改變處理資格、庫存數量或營運判斷的情況：

這些是待核對的問題，不能直接當成已決定的規格。文件或現有流程已有答案，就記下依據；找不到答案，或不同入口的行為不一致，再帶回團隊討論。

把例外寫成使用者看得懂的結果

假設團隊確認：已由其他工作完成的訂單，不再執行扣減，但原批次仍要留下這筆項目的處理結果。

只顯示「失敗」，營運人員可能以為還要再處理；顯示「成功」，又可能讓人以為這次批次執行了扣減。可以和團隊確認是否顯示「已由其他作業完成，本次未執行」，並讓使用者查到目前的訂單結果。

如果無法確認庫存是否已扣減，也不能直接顯示「扣減失敗，可重新送出」。工作本身的執行結果，與庫存實際發生的事情，需要分清楚，使用者才知道下一步能做什麼。

重新檢查，也要確認能守住規則

執行前再查一次狀態，能發現等待期間的變化。但如果兩個工作幾乎同時查詢，都看到允許補送，再各自呼叫庫存服務呢？

因此，重新檢查本身還不能保證不會重複扣減。還要核對既有的工作協調方式，以及庫存端如何辨識同一筆操作。安全重試的設計留到Day14，這裡先確認「同一筆扣減不能因多個入口而多做一次」的規則。

流程中間有等待、又有多個入口時，「檢查通過」只代表檢查當下成立。執行時能不能處理、使用者會看到什麼，都要依執行當下的狀態決定。

明天回到這個後台功能本身：如果系統已經能查明庫存結果，並安全地接續處理，營運人員還需要一直按「重新處理」嗎？

寫到「排進佇列的時候，世界沒有跟著暫停」，突然覺得這句話也很適合放在自己的待辦清單上。
早上排好要回的信，下午打開才發現，同事已經回過了。
而我差一點又寄出一封，內容還跟他的不一樣。