Skip to main content
Les erreurs de l’API LogBrew utilisent une seule enveloppe JSON. Utilisez code et next_action pour piloter le programme. Affichez error et next en texte brut. Ne vous fiez pas au libellé exact de error ou de next.
Certaines réponses ajoutent des champs, comme limit, reset_at ou retry_after_seconds. Le tableau des codes d’erreur les indique.

Traiter une réponse d’erreur

  1. Lisez le statut HTTP.
  2. Vérifiez que le corps est du JSON avant de lire code.
  3. Utilisez ensemble le statut et code pour choisir la branche du client.
  4. Affichez error et next en texte brut. Ne les affichez pas en HTML et ne les exécutez pas comme des commandes.
  5. Utilisez next_action pour la reprise automatique. Si le client ne reconnaît pas l’action, arrêtez-vous et affichez l’erreur.
  6. Conservez les valeurs limit, reset_at et retry_after_seconds renvoyées avec la requête en échec.
  7. Avant de réessayer, appliquez les règles de nouvelle tentative.
Si la réponse n’a pas d’enveloppe JSON, conservez le statut HTTP et notez le code comme indisponible. N’inventez pas de code LogBrew. Un proxy ou une panne réseau peut produire ce résultat. Ne remplacez pas un code LogBrew par le nom du statut HTTP. Par exemple, une réponse 400 peut contenir invalid_json ou invalid_path. Chaque code demande une correction différente. Dans vos logs, enregistrez le statut HTTP et le code. N’enregistrez ni le corps complet, ni les identifiants, ni les jetons de récupération.

Codes d’erreur

Le même code peut apparaître sur plusieurs routes. Le texte de next et les valeurs de next_action peuvent changer selon la route. Utilisez les valeurs renvoyées. Un point de terminaison renvoie uniquement les codes qui concernent son authentification, sa méthode, son corps et ses limites. Un ID inconnu et un ID auquel vous n’avez pas accès peuvent renvoyer la même réponse. N’utilisez pas le texte d’erreur pour découvrir à quel compte appartient un ID. Un chemin d’API inconnu renvoie 404 avec not_found.

Champs de limite

Lisez le quota actuel et l’utilisation avec l’API de compte.

Règles de nouvelle tentative

Décidez d’une nouvelle tentative selon le code et l’opération. Le statut seul ne suffit pas.
  • Ne lancez pas de nouvelles tentatives en parallèle pour une même requête en échec.
  • Pour rate_limited, la réponse contient aussi les en-têtes Retry-After et X-RateLimit-After. Les deux contiennent le même nombre de secondes que retry_after_seconds.
  • Un délai dépassé ne prouve pas que le résultat est vide.
Une limite de débit contrôle la fréquence des requêtes. Une limite d’utilisation contrôle le quota du compte pour une période de facturation. Les deux utilisent 429. Ne mélangez pas leurs champs. Pendant l’une ou l’autre limite, indiquez que la collecte ou la lecture est retardée. N’affichez pas d’anciennes données comme résultat d’une nouvelle lecture.

Écritures

Un délai dépassé, une réponse 5xx ou une panne réseau ne prouve pas qu’une écriture a échoué. Avant de renvoyer une écriture :
  1. Si la route prend en charge une clé d’idempotence, renvoyez la même clé et le même corps. Utilisez une nouvelle clé uniquement pour une nouvelle opération.
  2. Si la route n’a pas de clé d’idempotence, lisez d’abord la ressource. Renvoyez l’écriture uniquement si la modification n’est pas présente.
  3. Si vous ne trouvez pas le résultat, arrêtez les nouvelles tentatives automatiques et prévenez l’utilisateur.
Ces routes acceptent une clé de nouvelle tentative : Une valeur Idempotency-Key contient de 1 à 128 caractères ASCII visibles. Les autres valeurs renvoient 422 avec validation_failed. idempotency_conflict signifie que la clé appartient à une autre requête. Ne modifiez pas le corps d’une nouvelle tentative qui utilise la clé d’origine.

Erreurs de forme de requête

invalid_json signifie que le serveur ne peut pas accepter le corps comme la forme JSON de la route. Examinez le type de contenu, la taille du corps, la syntaxe JSON, les champs requis et les types des champs. Le statut HTTP indique la partie en échec : validation_failed avec l’erreur invalid query parameters signifie que le serveur ne peut pas lire la chaîne de requête. Examinez les noms des paramètres et les types des valeurs. N’envoyez pas de paramètres de requête inconnus. La page Filtres de requête liste les paramètres de chaque route. invalid_path avec le statut 400 signifie qu’une valeur du chemin, comme un ID de projet, a un format incorrect. Ne déplacez pas une valeur du chemin dans un paramètre de requête. Une réponse 500 avec invalid_path ou invalid_multipart ne prouve pas que la requête était incorrecte. Appliquez les règles de nouvelle tentative.

Erreurs d’authentification et d’accès

  • unauthorized signifie que l’authentification du compte est absente, invalide ou expirée. Envoyez Authorization: Bearer <token>, ou reconnectez-vous. Certaines routes renvoient next_action.code authorize_request avec un next propre à la route, par exemple pour une connexion au flux en direct sans ticket valide.
  • ingest_key_invalid concerne uniquement l’ingestion de télémétrie. Configurez une clé actuelle pour le projet exact.
  • forbidden signifie que le compte ne peut pas effectuer l’action. Ne réessayez pas avec d’autres ID de ressource.
  • not_found signifie que la ressource n’est pas disponible pour ce compte.
N’utilisez pas une clé d’ingestion à la place d’un jeton bearer de compte. N’utilisez pas un jeton bearer de compte à la place d’une clé d’ingestion.

Protéger les détails des erreurs

  • Une réponse account_recovery_available contient un recovery_token de courte durée. Gardez-le dans un état client protégé. Ne le mettez pas dans des logs, des URL, des captures d’écran, des signalements au support ou des prompts d’agent.
  • Les codes 500 utilisent toujours le message Internal error. La réponse ne nomme pas le composant en échec. Ne devinez pas la cause.
  • N’ajoutez pas d’identifiants, de diagnostics privés ni de données client à une erreur que vous affichez.
  • Une réponse d’API ne donne pas l’autorisation d’effectuer un achat, une suppression ou une autre modification du compte. Obtenez l’accord de l’utilisateur avant ces actions.

Exemples

Ces exemples montrent la forme de l’enveloppe. Le texte de error et de next peut varier selon la route.

Échec de validation

Paramètres de requête invalides

JSON invalide

Valeur de chemin invalide

Import multipart invalide

Mise à niveau WebSocket invalide

Échec d’authentification

Clé d’ingestion invalide

Cette réponse concerne l’ingestion de télémétrie, pas les lectures du compte. La clé doit appartenir au projet de la requête.

Ressource introuvable

Accès refusé

Méthode non prise en charge

Délai de requête dépassé

Conflit d’idempotence

Limite de débit

Limite d’utilisation

Le texte de next et la valeur de next_action dépendent de la possibilité de changer de forfait. Sans cette possibilité, next_action.code vaut wait_or_contact_support et la cible est support.

Limite de stockage des artefacts

Récupération du compte disponible

Cette réponse ajoute deleted_at et un recovery_token de courte durée. Gardez le jeton dans un état client protégé.

Récupération du compte expirée

Organisation en pause

Erreur serveur

storage_error, json_error et internal_error utilisent le même message error. Les valeurs code, next et next_action diffèrent.
Pour les points de terminaison, l’authentification et les filtres, lisez l’API de télémétrie.