失敗には送り直せば通るものと、何度送っても通らないものがあります。この2つを分けないと、どちらかで損をします。
1000件の失敗を仕分けて数えました。番号が500番台のものだけ送り直すと235件を取りこぼします。1種類足すだけで1000件すべて正しく分かれました。
失敗1000件を3通りの分け方で仕分けました。1種類の扱いを変えるだけで結果が大きく動きます。
エラー処理設計で分け方を変えると何が変わるのかを、実際に走らせて数えました。用意したのは8種類の失敗、合計1000件です。
それぞれの種類に送り直せば通るかどうかを持たせています。分け方が正しいかを、この性質と突き合わせて数えました。
const WAYS = [ ['全部を送り直す', () => 'temp'], ['5xx だけ送り直す', (e) => (e.code >= 500 ? 'temp' : 'perm')], ['5xx と 429 を送り直す', (e) => (e.code >= 500 || e.code === 429 ? 'temp' : 'perm')], ];
失敗 1000件。うち送り直せば通るもの 629件・何度送っても通らないもの 371件 分け方 正しく分けられた 取りこぼし 無駄な送り直し 全部を送り直す 629 / 1000 0件 1484回 5xx だけ送り直す 765 / 1000 235件 0回 5xx と 429 を送り直す 1000 / 1000 0件 0回 コード 内容 件数 送り直せば通るか 429 要求が多すぎます 235件 はい 503 一時的に利用できません 187件 はい 400 項目の形式が違います 141件 いいえ 404 宛先が見つかりません 108件 いいえ
上の表を見てください。番号が500番台のものだけ送り直すと、235件を取りこぼしました。
取りこぼした235件は、すべて429という1つの種類でした。この種類だけを足すと1000件すべて正しく分かれます。
429は400番台です。番号の範囲だけで見ると送り直しても無駄な側に入ります。ところが実際は待てば通ります。
1行目は取りこぼしが0件です。代わりに1484回の無駄な送り直しが出ました。
宛先が見つからない、形式が違うといった失敗を5回ずつ繰り返した結果です。相手にも自分にも負担がかかります。
1種類の扱いで、取りこぼしが235件から0件になる。
status code indicates the client has sent too many requests in a given amount of time.原文MDN「429 Too Many Requests」 この内容の有効期限2027-02-18
失敗を種類ごとに分け、それぞれをどう扱うかを決めます。分け方が決まっていないと、扱いも決まりません。
エラー処理設計は、失敗を分けて、それぞれの扱いを決めることです。
いちばん大事な分け目は送り直せば通るかどうかです。ここが決まれば、扱いも決まります。
4番目を見落としがちです。すでに登録されているという応答は、二重に届いた場合には成功として扱えます。
番号だけが手がかりではありません。どれだけ待てばよいかを示す情報が付いてくることがあります。
MDNも429について、もう一度要求する前にどれだけ待つべきかを示すため、この応答に見出し情報が含まれることがあると説明しています。付いていれば、待ち時間を自分で決める必要がありません。
同じ429でも、相手のシステム全体が混んでいるのか、特定の宛先だけなのかで対処が変わります。
MDNは、この仕組みを要求の速さを落とすよう相手に求めるものだと説明しています。相手全体が混んでいるなら、送る量そのものを落とす必要があります。
失敗の種類と割合はこちらで置いた値です。実際の割合は相手のシステムと自分の使い方で変わります。ここで見せているのは、割合が偏っている種類を1つ落とすと結果が大きく動くという関係です。まず自分の失敗を種類ごとに数えてください。
header may be included to this response to indicate how long a client should wait before making the request again.原文MDN「429 Too Many Requests」 この内容の有効期限2027-02-18
先に網羅的な分類を作る必要はありません。実際に返ってきた種類を数えて、多いものから決めていけば足ります。
エラー処理設計を始めるとき、すべての失敗を先に想定しようとすると終わりません。実際に返ってきたものから決めます。
前の節の計測では、8種類のうち429だけで235件と最も多くなりました。上位から見ていけば、少ない手数で大半が片付きます。
数えるには記録が要ります。失敗の内容を残していないと、どの種類が多いかも分かりません。
よくあるのは、失敗を捕まえて何もせずに次へ進む作りです。処理は止まりませんが、記録も残りません。
この状態では、前の節のような表が作れません。分けようがないので、設計そのものが始められません。
4番目があるので、3番目を全部やる必要はありません。決めていない種類も、既定の扱いで安全側に倒れます。移した先の扱いはデッドレターキューの記事で扱っています。
記録がなければ数えられず、数えられなければ分けられない。
This mechanism of asking the client to slow down the rate of requests is commonly called原文MDN「429 Too Many Requests」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る