舊 webhook 必須先排空再切金鑰

舊 webhook 仍持有 in-flight DLR 時切金鑰，會把投遞真相扔在半空。買家看到 sent 卻無最終狀態；財務看到永不關閉的 hold；ops 失去證明 failover 順序的軌跡。先排空。再切割。

IOSOR 輪換把舊 endpoint 當作必須安靜的佇列——不是新 URL 答了一次 smoke 就扳動的開關。in-flight 報告屬於訊息生命週期；孤兒化它們會發明一週幽靈列。

清點舊 endpoint 上的 in-flight DLR

匯出綁定舊 webhook URL 的未完成投遞與 pending 最終狀態。給每列打上年齡與 message id。這份清單是排空 backlog——不是「重試總會跑完」的模糊希望。

在任何人安排金鑰撤銷前把匯交給財務。若 backlog 超過一個安靜班次，書面延長排空視窗，而不是切進晚到 DLR 風暴。

排空到 quiet，然後切金鑰

舊 endpoint 僅對 completion 事件保持 Live，直到清單歸零或約定殘留下限。排空列表仍有新到達時，不要撤銷 messaging 或 webhook 金鑰。quiet 是測量視窗內無新 final——不是「Slack 看起來平靜」。

quiet 證明後，在與唯一擁有者 URL 切換同一變更視窗撤銷舊金鑰。留下半活金鑰的部分撤銷，會讓晚到 DLR 落在死路徑。

排空期間保持 failover 順序誠實

排空時不要發明繞過有序備份故事的第二條 Live 路徑。failover 仍是 primary-then-backup；排空不是扇出許可。寫明哪條路徑擁有 in-flight 列，避免事故週爭論哪根管子「本該」應答。

若 primary 在排空中途失敗，走有序備份並重新清點——不要用恐慌式切金鑰來「簡化」。

切割後重新證明 day-1 runway

切金鑰後跑 day-1 必須綠燈的檢查：heartbeat、傳送證明、新 endpoint 的 webhook finals、錢包 hold 關閉。然後才重開試點量。舊路徑已排空但 runway 仍紅，仍是被擋的上線。

匯出新 URL 上第一個安靜小時，讓 ops 向買家證明 DLR 沒有隨舊金鑰消失。

相關營運路徑

• 在不遺失派送報告的情況下輪替 Webhook 簽章密鑰
• 第一天跑道：必須亮綠燈的事項
• 無重複扣款的備援路徑

從 IOSOR 開始

匯出舊 endpoint backlog，排空到 quiet，然後在唯一擁有者 URL Live 時撤銷金鑰。在新路徑重跑 day-1 runway，並對任何排空中途事故書面保留 failover 順序，再提高量。 割接前把 spend 證明與買家文案清洗寫進同一份密封地圖，財務簽字後再換 Live 金鑰。 佇列未 quiet 前不要封存舊 endpoint，也不要切金鑰。

IOSOR 要點

切金鑰前先排空舊 webhook：in-flight DLR 是你仍欠的真相。清點、quiet、撤銷，再重證 runway——不要為了好看的割接日曆而孤兒化 finals。