dosya CLIの終了コードを処理する

dosya CLIの終了コードでスクリプトを分岐し、標準エラー出力を保持して、使い方、認証、ネットワーク、権限、メンテナンスの失敗を区別します。

dosya CLIは自動化用に安定したプロセスステータスを使います。0は成功、1は一般的な失敗、2は使い方の誤り、3は認証、4はネットワーク、5は権限拒否、75はメンテナンスを表します。シグナルによる終了はSIGINTが130、SIGTERMが143のままです。

始める前に

標準出力、標準エラー出力、$?を別々に取得してください。通常のテキストとJSONは標準出力に、診断情報、警告、デバッグ出力、進捗は標準エラー出力に出力されます。
ジョブで再試行できる分類を決めてください。認証と権限の失敗は修正が必要です。短い間隔で繰り返し再試行しないでください。
コードがsurface_disabledの503レスポンスは、メンテナンスの終了コード75に直接対応します。

標準出力を別のプロセスに直接パイプせずにコマンドを実行し、まず両方のストリームと元の終了ステータスを保持してください。
0はコマンドの成功として扱ってください。一括コマンドを--json付きで実行した場合、1件以上失敗すると通常はコマンド固有のJSONを出力して終了コード1で終了します。その結果を解析し、成功件数と失敗の詳細を保持してください。
2は無効なコマンド構文または引数、3は認証情報の欠落または拒否、5は認証済みの実行者に権限がない場合に対応させてください。
4は転送または接続の失敗に対応させてください。コマンド自体を安全に繰り返せる場合に限り、回数を制限して再試行してください。
75はsurface_disabledを含む一時的なメンテナンスに対応させてください。恒久的な設定エラーとして扱わず、運用担当者が承認した待機時間の後に再スケジュールしてください。
標準エラー出力と数値のステータスを記録してください。130と143はキャンセルとして保持し、スケジューラーが中断されたジョブをアプリケーションの失敗と誤認しないようにしてください。

自動処理は元の数値ステータスで分岐し、標準エラー出力の診断情報を保持します。エラーメッセージを解析して、使い方、認証、ネットワーク、権限拒否、メンテナンスのどれによる失敗かを推測することはありません。

パイプラインがパーサーのステータスを報告する場合 jqを実行する前にdosyaのプロセスステータスを保存するか、シェルのパイプラインステータスの処理を明示的に有効にしてください。

終了コード1の詳細が少ない場合 標準エラー出力を確認してください。1は、より限定されたステータスに対応しない失敗の一般的な分類です。

再試行するとデータが二重に変更される可能性がある場合 まずリモートの状態を確認してください。終了コードは失敗の分類を示しますが、接続が切れる前にサーバーが変更を確定したかどうかは示しません。