ドキュメント処理がタイムアウトします。1 つのタスクがバッチ全体を引きずらないようにしてください

ドキュメントをバッチで処理する場合、多くの場合、最も問題となるのは 1 つのファイルのエラーではなく、1 つのタスクがスタックし、後続のすべてのタスクがキュー内で停止することです。たとえば、スキャンした PDF がスタックした場合、次の 99 個のタスクは移動しません。リクエストにタイムアウトを追加すると、この問題が解決されるようです。

しかし、タイムアウトは課題が終わったという意味ではありません。処理はバックグラウンドで実行されメモリを消費し続け、製品が半完成品であることもあります。タイムアウトには少なくとも3つの動作が含まれます:待機停止、実行停止、そして製品を配達不可としてマークすること。この記事を読めば、タイムアウト後に記録すべき証拠、再試行が適切な状況、クライアントの待ち時間とリモートタスクの状態を区別する方法を判断できるはずです。

本論文では合成試料を用いた処理方法を実証します。コードは孤立した環境でのサンプルチェックを通過しており、すべての本物のファイルや製品の有効性を保証するわけではありません。重要な書類を扱う前に、原本を保管し、書類の境界線や受理項目に従って確認してください。

一文の結論

バッチタスクのタイムアウトは3つの方法で処理すべきです:待機停止、実行停止、製品を配送不可としてマークすること、そして「待機タイムアウト」を直接「タスク終了」として扱わないことです。

あなたの状況	推奨レシピ	理由
ページまたはキューがスタックするのを止めたいだけです	待つのをやめて、既知のタスク状況を問い合わせてください	待機を終わらせたからといって、リモートミッションが終わったわけではありません
バックグラウンドプロセスがメモリを占有しているのではないかと心配しています	終了が完了したかどうかを確認し、必要に応じてプロセスグループ、コンテナ、ジョブオブジェクトで分離してください	`subprocess.run(timeout=...)`は直接子プロセスに動作し、クリーンアップされたプロセスツリー全体に一般化することはできません
製品は半完成品の場合もあります	一時的な製品を配達不能としてマークし、ステータスを正式な結果と共有しない	制限時間内に遅れて到着した場合、タスクを「成功」に変更することはできません
同じ入力が繰り返しタイムアウトします	サンプルを分離し、複雑さをチェックする。無制限の再試行は行わない	再試行は、失敗が回復でき、呼び出しが適切な冪起こしを持つ場合にのみ意味を持ちます

タイムアウトを待つことは、作業が終わったという意味ではありません

タイムアウトは通話者にのみ影響します

subprocess.run(timeout=...)は直接子プロセスのタイムアウトは可能ですが、すべてのプロセスツリーがクリーンアップされている保証はありません。異なるオペレーティングシステム、起動方法、サブルーチンの挙動によって結果が変わります。関連する挙動はPythonサブプロセスのタイムアウト動作で参照できます。

生産環境には隔離戦略が必要です

本番環境の実装では、関連する作業がタイムアウト後に本当に停止するようにするため、プロセスグループ、コンテナ、作業オブジェクトなどの分離措置が通常必要です。

まずタスクステータスコントラクトを明確に書きます

以下はステータス判定をシミュレートするだけであり、外部コマンドを開始したり、プロセスを意図的に一時停止したりするものではありません。このデモンストレーションの重要な点は、期限に達した後、ワークユニットの結果が遅れて到着したとしても、タイムアウトしたタスクを直接成功に変更することはできないということです。

from dataclasses import dataclass

@dataclass(frozen=True)
class Decision:
    state: str
    deliver: bool
    terminate_requested: bool

def decide(now, deadline, worker_done, artifact_valid):
    if now >= deadline:
        return Decision("timed_out", False, not worker_done)
    if not worker_done:
        return Decision("processing", False, False)
    if not artifact_valid:
        return Decision("invalid_artifact", False, False)
    return Decision("verified", True, False)

assert decide(9, 10, False, False).state == "processing"
assert decide(10, 10, False, False).terminate_requested
assert not decide(11, 10, True, True).deliver
assert decide(9, 10, True, True).deliver
assert decide(9, 10, True, False).state == "invalid_artifact"

このプロトコルは、期限に等しいタイムアウトを選択します。別の境界を使用することもできますが、それをテストに書き込む必要があります。リアルタイム比較では、計算間隔に適切な単調クロックを使用する必要があり、システムのタイムゾーンや実時間の調整によってタスクバジェットが変更されることは許可されません。

📊 コアの比較

アクション	問題は解決しました	まだまだ注意が必要なこと
待つのをやめる	発信者が動けなくなることはなくなりました	リモートまたはバックグラウンド作業がまだ進行中の可能性があります
実行の停止	プロセスが占有しているリソースを解放します	リクエストの終了は終了を意味するものではなく、確認が必要です。
商品を配送不可としてマークする	半製品の誤納品を防止	公式結果とは別にステータスを保存する必要がある

タイムアウト後にはどのような証拠が残されますか?

タイムアウト発生後は、タイムアウトを 1 回だけログに記録することはできません。次の情報は、問題の場所を特定するのに役立ちます。

知っておくべきこと	使用	知らせ
タイムアウトフェーズ	ダウンロード、解析、翻訳の区別	一度のタイムアウトだけじゃない
解雇が確定するかどうか	バックエンド作業が取り残されないようにしましょう	解雇を申請することは、あなたが辞退したという意味ではありません
一時的な製品アイデンティティ	未完成品を誤って納品しないようにしましょう	公式結果とステータスを共有しない
再挑戦カウント	全体の予算を管理	毎回無制限に時間を回復することはできません

再挑戦は自動的に次のステップではない

同じステップで資源が繰り返し使い果たされる場合は、まず確認してください

同じ入力が毎回同じステップでリソースを使い果たす場合は、サンプルを分離して複雑度の問題を確認し、再試行は避けてください。

2種類のヒントの区別

ユーザーは2つのシナリオを区別できるはずです。

サービス中、再試行中:待ってていいよ。
入力がサポートされていない、処理が必要:手動介入または入力の置き換えが必要です。

🎯 どの方法があなたに合いますか?

大量の書類を扱う場合

各タスクには独立したカットオフ時間が設定されており、単一のタスクが超過すると、そのタスクだけがマークし、バッチ全体が停止するのを防ぎます。

資源の漏洩を心配しているなら

タイムアウト後、終了が本当に完了しているかを確認し、直接的な子プロセスのタイムアウトだけに頼るのではなく、コンテナやプロセスグループレベルで隔離してください。

オンライン翻訳プラットフォームとつながりたいなら

クライアントの待ち時間、プラットフォームの処理状況、ファイルのダウンロード状況は別々に表示されるべきです。再度クリックする前に、重複消費を避けるために既知のタスクを確認してください。

❓ よくある質問(FAQ)

1. リクエストがタイムアウトしているなら、なぜ実行を停止するのでしょうか?

タイムアウト後も処理はバックグラウンドで実行されメモリを消費している可能性があります。待機を停止してもこれらのリソースが自動的に解放されるわけではありません。

2. タイムアウト後にミッションは必ず失敗するのでしょうか?

必ずしもそうとは限りません。しかし、タイムアウト後にタスクが遅延した場合、それを直接成功したタスクに変更することはできません。ステータス契約に基づいて判断する必要があります。

3. 再挑戦はいつ適切ですか?

リトライは、失敗原因が回復でき、コールが適切な冪元を持つ場合にのみ意味を持ちます。同じ入力が毎回同じステップでリソースを使い果たす場合は、まず分離とトラブルシューティングを行うべきです。

4. 期限切れ後にどのような証拠を記録すべきでしょうか?

最低限、タイムアウトフェーズ、終了確認済み、一時的な製品識別、必要な再試行回数を記録してください。

📝 概要

タイムアウトの鍵は「待つことをやめること」「実行を停止すること」「製品が納品可能かどうか」を分けることです。タスクの状態がクリアになると、バッチが単一のファイルで下に引きずられることはありません。

今すぐ体験:元のフォーマットを保ちながら翻訳を始めるために文書をアップロードしましょう