Operator requeue

Requeue 是佇列交付復原，不是重做業務決策。當 worker 在「資料庫已留下 pending/running 狀態」後崩潰，工作可以重新送出；處理器會利用既有 run / staged-change 狀態續跑。每一次 root scheduler tick 都已經會執行這兩種掃描（超過 300 秒的 trigger run，最多 500 筆；staged change，最多 500 筆），並回報為 trigger_runs_requeued / staged_changes_requeued。下面的端點是在需要時或以更大批次執行同一套掃描。

Ops audience 本頁兩個 hotfix 端點只供受控平台 operator 使用，需要 CloudManager root credentials（X-ADMIN-TOKEN、X-SUPER-TOKEN、X-CLOUD-TOKEN）。不可由租戶 UI、callback consumer 或一般 application job 呼叫。

Trigger run 批次 requeue

curl -X POST \
  "$BASE_URL/root/hotfix/custom-table-trigger-runs/requeue?older_than_seconds=300&limit=500" \
  -H "X-ADMIN-TOKEN: $ADMIN_TOKEN" \
  -H "X-SUPER-TOKEN: $SUPER_TOKEN" \
  -H "X-CLOUD-TOKEN: $CLOUD_TOKEN"

它挑選建立時間早於 older_than_seconds 的 pending runs，以及超過 300 秒（或 older_than_seconds，取較大者）沒有更新的 running runs；後者先重設為 pending。failed run 永遠不會被挑選，必須由 moderator 重試。Worker 仍採 resume 語意，略過既有 action_results 中已成功的 actions。回應只有本次 requeued 數量：

{ "requeued": 14 }

older_than_seconds 最小為 0、預設 300；limit 為 1..2000、預設 500。先用保守 limit，觀察 queue depth 與 downstream rate，再分批增加。

完整 contract 見 root.hotfix.triggerRunsRequeue。

Staged change 批次 requeue

Approval process 已通過，但 apply worker 未完成時，使用獨立端點：

curl -X POST \
  "$BASE_URL/root/hotfix/custom-table-staged-changes/requeue?limit=500" \
  -H "X-ADMIN-TOKEN: $ADMIN_TOKEN" \
  -H "X-SUPER-TOKEN: $SUPER_TOKEN" \
  -H "X-CLOUD-TOKEN: $CLOUD_TOKEN"

它不會代替 reviewer 作決定，只復原已符合重新排隊條件的 staged-change apply：Review 流程已經 approved、rejected 或 cancelled，卻仍停在 pending 的列，以及停在 applying 且 600 秒沒有心跳的列。每一列都會重新派送其流程的終局決定，所以有好幾列的流程會依列各派送一次；requeued 只計算成功的派送，重複執行是安全的。limit 為 1–2000（預設 500），而每次排程 tick 本來就會以 500 的上限跑同一個清掃。端點見 root.hotfix.stagedChangesRequeue。

選擇正確的恢復路徑

每次操作都應記錄查詢參數、回應數量與前後 failed/stuck 指標；避免無界、緊密迴圈反覆 requeue。