このドキュメントは英語の原文から自動翻訳されています。表現に不自然な箇所がある場合があります。正確な内容は英語の原文もあわせてご確認ください。
429、408、500、ネットワーク切断）は、あらゆるネットワークサービスで通常発生します。適切な対応は、ジッター付きの指数バックオフをリトライ可能なエラーに対してのみ適用することです。両方のSDKは、すぐに使える設定可能なリトライポリシーを標準で備えています。
リトライ対象
SDKの設定
両方のSDKは、クライアントレベルおよび呼び出し単位でリトライ設定を受け付けます。- Python
- TypeScript
429、5xx）に対して指数バックオフでリトライを行い、リトライ間隔は最大1分、合計時間は最大1時間に制限されます。レイテンシSLOに合わせて数値を調整してください。
手動リトライパターン
REST APIを直接呼び出す場合や、SDKを独自のロジックでラップしたい場合：適切なバックオフの選択
- レート制限による
429— 初期待機500〜1000 msを倍増させ、30〜60秒まで。リトライは3〜5回で打ち切ってください。 - 一時的なエラーによる
500/5xx— 同じ形状で、初期値を少し短く（300 ms）。通常は素早く解消するためです。 - ストリーミングリクエスト — 再生を開始していない場合は、部分的なストリームのリトライは問題ありません。再生が始まった後は、新しい音声を継ぎ足すよりも失敗させる方が通常は良いでしょう。UXに基づいて判断してください。
- 長文の自動チャンク分割 — 両方のSDKは、内部の各セグメントに同じリトライポリシーを適用します。そのため、1回の長文呼び出しはセグメント単位でリトライ予算を持つことになります。
冪等性
Supertone API呼び出しは結果として冪等です — 同じリクエストは同じ音声出力（合成のわずかなばらつきを除く）を生成します。成功したものの中断されたリクエストをリトライしても、元のリクエストが課金対象の音声を生成していない限り、クレジットが二重に請求されることはありません。 ボイスクローンのアップロードについては、アップロードが完了した場合はリトライのたびに別々のボイスが作成されます。ネットワークの瞬断後に再アップロードする場合は、再投稿する前に前回の試行が実際に完了しているかを確認してください。そうでないと、list_custom_voicesに重複したボイスが残ってしまいます。
避けるべきアンチパターン
4xx（429以外）のリトライ — 時間が経っても改善しません。リクエストを修正してください。- 上限なし — 試行回数と合計経過時間には必ず上限を設けてください。
- ジッターなし — 固定遅延のリトライは、広範な障害発生時にサンダリングハード（thundering herd）パターンを引き起こします。
- バックオフなしのループ内リトライ — クレジットとレート制限の予算を数秒で使い切ります。
関連項目
レート制限
そもそも何が
429を引き起こすのか。エラー処理
エラーコードとSDKエラークラスの完全リファレンス。