Skip to main content
LogBrew API のエラーは、1つの JSON エンベロープを使います。プログラムの動作には code と next_action を使います。error と next はプレーンテキストとして表示します。error や next の文言で照合しないでください。
レスポンスによっては、limit、reset_at、retry_after_seconds などのフィールドが追加されます。エラーコードの表に記載しています。

エラーレスポンスを処理する

  1. HTTP ステータスを読みます。
  2. code を読む前に、本文が JSON であることを確認します。
  3. ステータスと code を組み合わせて、クライアントの分岐を選びます。
  4. error と next はプレーンテキストとして表示します。HTML としてレンダリングしたり、コマンドとして実行したりしないでください。
  5. 自動の復旧には next_action を使います。クライアントがそのアクションを認識できない場合は、処理を止めてエラーを表示します。
  6. 返された limit、reset_at、retry_after_seconds の値を、失敗したリクエストと一緒に保持します。
  7. 再試行する前に、再試行のルールを確認します。
レスポンスに JSON エンベロープがない場合は、HTTP ステータスを保持し、コードは利用不可として記録します。LogBrew の code を作り出さないでください。プロキシやネットワークの障害で、このような結果になることがあります。 LogBrew の code を HTTP ステータスの名前で置き換えないでください。たとえば、400 のレスポンスには invalid_json や invalid_path が含まれることがあります。コードごとに必要な修正は異なります。 ログには、HTTP ステータスと code を記録します。本文全体、認証情報、復旧用のトークンはログに残さないでください。

エラーコード

同じ code が複数のルートで返ることがあります。next のテキストと next_action の値は、ルートによって変わることがあります。返された値を使ってください。エンドポイントが返すのは、その認証、メソッド、本文、上限に該当するコードだけです。 存在しない ID と、アクセスできない ID は、同じレスポンスを返すことがあります。エラーのテキストから、ID を所有するアカウントを探らないでください。存在しない API パスには、404 と not_found が返ります。

上限のフィールド

現在の許容量と使用量は、アカウント APIで確認します。

再試行のルール

再試行するかどうかは、コードと操作をもとに判断します。ステータスだけでは判断できません。
  • 1件の失敗したリクエストについて、並行して再試行を始めないでください。
  • rate_limited のレスポンスには、Retry-After ヘッダーと X-RateLimit-After ヘッダーもあります。どちらも retry_after_seconds と同じ秒数です。
  • タイムアウトは、結果が空であることの証明にはなりません。
レート制限は、リクエストの頻度を制御します。使用量の上限は、請求期間ごとのアカウントの許容量を制御します。どちらも 429 を使います。それぞれのフィールドは区別して扱います。どちらの上限に達している間も、データの収集や読み取りが遅れていることを表示します。古いデータを、新しい読み取りの結果として表示しないでください。

書き込み

タイムアウト、5xx のレスポンス、ネットワークの障害は、書き込みが失敗したことの証明にはなりません。書き込みをもう一度送信する前に、次を行います。
  1. ルートがべき等キーに対応している場合は、同じキーと同じ本文をもう一度送信します。新しいキーは、新しい処理の場合だけ使います。
  2. ルートにべき等キーがない場合は、先にリソースを読みます。変更が反映されていない場合だけ、書き込みをもう一度送信します。
  3. 結果を確認できない場合は、自動の再試行を止めて、ユーザーに伝えます。
次のルートは再試行キーを受け付けます。 Idempotency-Key の値は、表示可能な ASCII 文字 1〜128文字です。それ以外の値には、422 と validation_failed が返ります。 idempotency_conflict は、そのキーが別のリクエストに属していることを示します。元のキーを使う再試行では、本文を変更しないでください。

リクエストの形のエラー

invalid_json は、サーバーが本文をルートの JSON の形として受け付けられないことを示します。コンテンツタイプ、本文のサイズ、JSON の構文、必須のフィールド、フィールドの型を確認します。どの部分が失敗したかは、HTTP ステータスでわかります。 エラー invalid query parameters を伴う validation_failed は、サーバーがクエリ文字列を読み取れないことを示します。パラメーターの名前と値の型を確認します。不明なクエリパラメーターを送信しないでください。各ルートのパラメーターは、クエリフィルターに記載しています。 ステータス 400 の invalid_path は、プロジェクト ID などのパスの値の形式が間違っていることを示します。パスの値をクエリパラメーターに移さないでください。 invalid_path や invalid_multipart を伴う 500 のレスポンスは、リクエストが間違っていたことの証明にはなりません。再試行のルールに従います。

認証とアクセスのエラー

  • unauthorized は、アカウントの認証がない、無効である、または期限切れであることを示します。Authorization: Bearer <token> を送信するか、もう一度サインインします。一部のルートでは、有効なチケットのないライブフィードの接続など、next_action.code が authorize_request で、ルートごとの next が返ります。
  • ingest_key_invalid は、テレメトリの取り込みだけに適用されます。対象のプロジェクトの現在のキーを設定します。
  • forbidden は、アカウントがその操作を行えないことを示します。他のリソース ID で再試行しないでください。
  • not_found は、このアカウントではそのリソースを利用できないことを示します。
アカウントの Bearer トークンの代わりに取り込みキーを使わないでください。取り込みキーの代わりにアカウントの Bearer トークンを使わないでください。

エラーの詳細を安全に扱う

  • account_recovery_available のレスポンスには、有効期間の短い recovery_token が含まれます。保護されたクライアントの状態に保管します。ログ、URL、スクリーンショット、サポートの報告、エージェントのプロンプトには入れないでください。
  • 500 のコードでは、メッセージは常に Internal error です。レスポンスには、失敗したコンポーネントの名前は含まれません。原因を推測しないでください。
  • 表示するエラーに、認証情報、非公開の診断情報、顧客データを加えないでください。
  • API のレスポンスは、購入、削除、その他のアカウントの変更を許可するものではありません。これらの操作の前に、ユーザーの承認を得てください。

例

次の例はエンベロープの形を示します。error と next のテキストは、ルートごとに異なることがあります。

検証の失敗

無効なクエリパラメーター

無効な JSON

無効なパスの値

無効なマルチパートのアップロード

無効な WebSocket のアップグレード

認証の失敗

無効な取り込みキー

このレスポンスは、アカウントの読み取りではなく、テレメトリの取り込みに適用されます。キーは、リクエストのプロジェクトに属している必要があります。

リソースが見つからない

アクセスの拒否

対応していないメソッド

リクエストのタイムアウト

べき等性の競合

レート制限

使用量の上限

next のテキストと next_action は、プランを変更できるかどうかによって変わります。変更できない場合、next_action.code は wait_or_contact_support で、対象は support です。

ビルド成果物のストレージの上限

アカウントの復旧が可能

このレスポンスには、deleted_at と、有効期間の短い recovery_token が追加されます。トークンは、保護されたクライアントの状態に保管します。

アカウントの復旧期間の終了

組織の一時停止

サーバーのエラー

storage_error、json_error、internal_error は、同じ error のメッセージを使います。code、next、next_action の値は異なります。
エンドポイント、認証、フィルターについては、テレメトリ APIを参照してください。