インターフェースがエラーを報告した場合、再試行しますか?文書化タスクでは、まずどの障害を回復できるかを区別する必要があります。

エラーが報告された後に再試行するのが一般的ですが、無制限に無差別に再試行すると、不具合が拡大する可能性があります。権限エラー、アカウントの滞納、ファイルの破損、および一時的にビジーなサービスは、別の方法で処理する必要があります。

この記事は、ドキュメントの翻訳や変換などの非同期タスクを行う開発者や製品の学習者に適しています。これを読んだ後、まず失敗を分類し、次に待機する時間、最大試行回数、およびユーザーの介入が必要なタイミングを決定できます。

以下のコードとフローは、隔離された環境でテストされた合成サンプルに基づいています。これらは、すべての本物の文書や製品の効果を保証するものではありません。重要な書類は処理する前に原本を保管し、本文の範囲や受理事項に従って見直してください。

ドキュメントタスクがエラーを報告した後に再試行するにはどうすればよいですか?一文の結論

再試行するかどうかを決定する前に、まず失敗を分類します。一時的な失敗は制限されて取り消され、権限とアカウントの問題は停止されてユーザーに引き継がれ、入力エラーはユーザーの修正に委ねられます。

まず、再試行によって重複タスクが生成されるかどうかを判断します。

POST タイムアウトは特に厄介です。クライアントが応答を受信しない場合、それはサーバーがタスクを作成していないことを意味するものではありません。インターフェイスに冪等キーがなく、タスク クエリ メカニズムがない場合、ブラインド再送信により複数の変換タスクが作成される可能性があります。

したがって、再試行戦略は、HTTP ステータス コードだけを調べるのではなく、まずインターフェイス コントラクトに従う必要があります。

回数と待機予算を純粋関数として記述する

from enum import Enum

class Failure(Enum):
    TRANSIENT = "transient"
    AUTH = "auth"
    BILLING = "billing"
    INVALID_INPUT = "invalid_input"

def delay_for(kind, attempt, replay_safe):
    if type(attempt) is not int or attempt < 0:
        raise ValueError("invalid attempt")
    if not replay_safe or kind is not Failure.TRANSIENT:
        return None
    schedule = (1, 2, 4)
    return schedule[attempt] if attempt < len(schedule) else None

assert delay_for(Failure.TRANSIENT, 0, True) == 1
assert delay_for(Failure.TRANSIENT, 2, True) == 4
assert delay_for(Failure.TRANSIENT, 3, True) is None
assert delay_for(Failure.TRANSIENT, 0, False) is None
assert delay_for(Failure.BILLING, 0, True) is None
assert delay_for(Failure.INVALID_INPUT, 0, True) is None

このコードは再試行計画を計算するだけで、実際には待機せず、リクエストも送信しません。固定の 1 秒、2 秒、および 4 秒は総合デモンストレーションの値であり、一般的なサービス推奨値ではありません。

運用環境では、次の点も考慮する必要があります。

• サーバーから返された Retry-After
• 同時に多数のタスクが再開されるのを避けるためのランダムなジッター
• 全体の締め切り
• 同時実行数の制限

サーバーに必要な待機時間がローカル バジェットを超える場合、事前にリクエストを開始するのではなく、再試行を停止する必要があります。

エラーの種類はさまざまなアクションに対応します

論理タスクと試行レコードを保存する

ユーザー操作は論理タスクに対応し、この論理タスクでは複数の試行が可能です。開始時刻、失敗カテゴリ、およびリモート タスク ID が試行ごとに記録されます。最終的には、受け入れられた結果が 1 つだけ選択されます。

この利点は、再試行の問題をトラブルシューティングするときに完全な記録が残ると同時に、試行回数がユーザー リクエストの数として誤って計算されないことです。

📊 コアの比較

翻訳エクスペリエンスの安定性は明確な説明から生まれます

OmniDocに接続するとき、フロントエンドは現在のステータス (待機中か、再認証が必要か、アカウントを確認する必要があるか)をユーザーに明確に伝える必要があります。すべてを「建物」として表示しないでください。

ユーザーは、ステータスが表示されるタスクを待って終了することには抵抗がありますが、フィードバックなしにボタンを繰り返しクリックすることは望んでいません。

参考：Python enum。

🎯 どの方法があなたに適していますか?

サービスの復旧を待っている場合

制限付きバックオフを使用し、最大回数と合計待機時間を設定し、サーバーの Retry-After を尊重します。

権限またはアカウントに問題がある場合

自動再試行を停止し、ユーザーに再認証またはアカウント ステータスの確認を求めます。

入力ファイルの構造が間違っている場合

ファイルを送信する前に、ユーザーにファイルを修復してもらいます。同じファイルを再送信しないでください。

呼び出すインターフェイスが POST であり、タイムアウトになる可能性がある場合

まず、インターフェースが冪等キーまたはタスククエリをサポートしているかどうかを確認し、再送信するかどうかを決定します。

❓ よくある質問 (FAQ)

1. 報告されたすべてのエラーを直接再試行できますか?

できません。権限エラー、アカウントの滞納、ファイルの破損、一時的にビジーなサービスは個別に処理する必要があります。一時的な障害のみが制限付きバックオフに適しています。

2. タイムアウト後に POST を再度直接送信できますか?

直接再送信することはお勧めできません。クライアントが応答を受信しない場合、それはサーバーがタスクを作成していないことを意味するものではありません。冪等なキーまたはタスク クエリ メカニズムがない場合、タスクの重複が発生する可能性があります。

3. リトライ回数と待ち時間はどのように決定すればよいでしょうか?

固定された 1 秒、2 秒、4 秒は単なる合成デモです。運用環境は、Retry-After、ランダム ジッター、全体の期限、および同時実行制限を組み合わせて決定する必要があります。

4. 試行回数はユーザーリクエストの統計に影響しますか?

いいえ、ユーザー操作を論理タスクとして記録し、各再試行をタスクの下の試行レコードとして記録するだけです。

📝 概要

再試行の鍵は、回数を増やすことではなく、まず失敗の種類を区別してから、何をすべきかを決定することです。回復可能な障害は制限された方法で再試行され、人間による対応が必要な問題は適時にユーザーに返されます。

今すぐ試してみましょう: ドキュメントをアップロードして、元のレイアウトを保持したまま翻訳を開始します