# error-retry

## 解決什麼問題
外部 API 偶發 500 / timeout 是常態。寫死「打一次就放棄」太脆弱。
這個 pattern 提供標準 retry chain：失敗 → 等 5 秒 → 重試一次 → 還失敗才通知人。

## 怎麼觸發
```bash
curl -X POST https://cypher.arcrun.dev/webhooks/named/error_retry/trigger \
  -d '{
    "api_key":"ak_xxx",
    "target_url":"https://flaky-api.example.com/endpoint",
    "payload":{"x":1},
    "workflow_name":"my_workflow"
  }'
```

## 改成你自己的
- `wait_a_bit.seconds` 改延遲（指數 backoff：5, 15, 45 秒）
- 串更多 retry 節點（generic 寫 3-4 次足夠）
- `final_fail_notify` 換 email / pagerduty / slack 等
- 加 `if_control` 判斷 error 類型（4xx 不重試、5xx 重試）

## 為什麼這 pattern 重要
- arcrun 的 `ON_FAIL` 邊是宣告式 error handling，比寫 try/catch 直觀
- `wait` 零件不消耗 CPU（cypher-executor 排程 sleep 後恢復），比 setTimeout 健康
- 失敗最終要通知人，不能默默吞 — 通知本身也是 workflow 的責任

## 變體
- **Circuit breaker**：3 次連續失敗 → 寫 KBDB `circuit:open` flag → 後續 trigger 直接跳過
- **Dead letter queue**：失敗的 input 寫 KBDB type=dlq-input，方便事後手動重跑
- **Idempotency key**：retry 時帶同樣的 request_id，避免下游重複處理

## 學到什麼
- `ON_FAIL` 邊：節點失敗時走哪條
- `wait` 零件：宣告式 delay，不阻塞 worker（推到 paused-resume）
- `{{node_id.error}}` 取得失敗節點的錯誤訊息
- 把「最終失敗通知」當 workflow 一部分，不靠系統外部 monitoring