Skip to main content
Gli errori dell’API di LogBrew usano un unico envelope JSON. Usa code e next_action per il comportamento del programma. Mostra error e next come testo semplice. Non basarti sulla formulazione di error o next.
Alcune risposte aggiungono campi, come limit, reset_at o retry_after_seconds. La tabella dei codici di errore li indica.

Gestisci una risposta di errore

  1. Leggi lo stato HTTP.
  2. Verifica che il corpo sia JSON prima di leggere code.
  3. Usa insieme lo stato e code per scegliere il ramo del client.
  4. Mostra error e next come testo semplice. Non renderizzarli come HTML e non eseguirli come comandi.
  5. Usa next_action per il recupero automatico. Se il client non riconosce l’azione, fermati e mostra l’errore.
  6. Tieni i valori limit, reset_at e retry_after_seconds restituiti insieme alla richiesta non riuscita.
  7. Prima di riprovare, applica le regole per i nuovi tentativi.
Se la risposta non ha un envelope JSON, tieni lo stato HTTP e registra il codice come non disponibile. Non inventare un code di LogBrew. Questo risultato può derivare da un proxy o da un errore di rete. Non sostituire un code di LogBrew con il nome dello stato HTTP. Per esempio, una risposta 400 può contenere invalid_json o invalid_path. Ogni codice richiede una correzione diversa. Nei log, registra lo stato HTTP e code. Non registrare il corpo completo, le credenziali o i token di recupero.

Codici di errore

Lo stesso code può comparire su più route. Il testo di next e i valori di next_action possono cambiare in base alla route. Usa i valori restituiti. Un endpoint restituisce solo i codici che si applicano alla sua autenticazione, al metodo, al corpo e ai limiti. Un ID sconosciuto e un ID a cui non puoi accedere possono restituire la stessa risposta. Non usare il testo dell’errore per scoprire quale account possiede un ID. Un percorso API sconosciuto restituisce 404 con not_found.

Campi dei limiti

Leggi la quota attuale e l’utilizzo dall’API dell’account.

Regole per i nuovi tentativi

Decidi se riprovare in base al codice e all’operazione. Lo stato da solo non basta.
  • Non avviare nuovi tentativi in parallelo per una sola richiesta non riuscita.
  • Con rate_limited, la risposta contiene anche gli header Retry-After e X-RateLimit-After. Entrambi contengono lo stesso numero di secondi di retry_after_seconds.
  • Un timeout non dimostra che il risultato sia vuoto.
Un limite di frequenza controlla quante richieste invii. Un limite di utilizzo controlla la quota dell’account per un periodo di fatturazione. Entrambi usano 429. Tieni separati i loro campi. Durante uno dei due limiti, mostra che la raccolta o una lettura è in ritardo. Non mostrare dati vecchi come risultato di una nuova lettura.

Scritture

Un timeout, una risposta 5xx o un errore di rete non dimostrano che una scrittura sia fallita. Prima di inviare di nuovo una scrittura:
  1. Se la route supporta una chiave di idempotenza, invia di nuovo la stessa chiave e lo stesso corpo. Usa una nuova chiave solo per un nuovo lavoro.
  2. Se la route non ha una chiave di idempotenza, leggi prima la risorsa. Invia di nuovo la scrittura solo se la modifica non è presente.
  3. Se non riesci a trovare il risultato, interrompi i nuovi tentativi automatici e avvisa l’utente.
Queste route accettano una chiave per i nuovi tentativi: Un valore di Idempotency-Key ha da 1 a 128 caratteri ASCII visibili. Altri valori restituiscono 422 con validation_failed. idempotency_conflict significa che la chiave appartiene a una richiesta diversa. Non cambiare il corpo di un nuovo tentativo che usa la chiave originale.

Errori nella struttura della richiesta

invalid_json significa che il server non può accettare il corpo come struttura JSON della route. Controlla il tipo di contenuto, le dimensioni del corpo, la sintassi JSON, i campi obbligatori e i tipi dei campi. Lo stato HTTP indica quale parte non è valida: validation_failed con l’errore invalid query parameters significa che il server non riesce a leggere la query string. Controlla i nomi dei parametri e i tipi dei valori. Non inviare parametri di query sconosciuti. Il riferimento dei filtri di query elenca i parametri di ogni route. invalid_path con stato 400 significa che un valore del percorso, come un ID progetto, ha un formato sbagliato. Non spostare un valore del percorso in un parametro di query. Una risposta 500 con invalid_path o invalid_multipart non dimostra che la richiesta fosse sbagliata. Applica le regole per i nuovi tentativi.

Errori di autenticazione e di accesso

  • unauthorized significa che l’autenticazione dell’account manca, non è valida o è scaduta. Invia Authorization: Bearer <token>, oppure accedi di nuovo. Alcune route restituiscono next_action.code authorize_request con un next specifico della route, come per una connessione al flusso in tempo reale senza un ticket di connessione valido.
  • ingest_key_invalid si applica solo all’ingestione della telemetria. Configura una chiave attuale per il progetto esatto.
  • forbidden significa che l’account non può eseguire l’azione. Non riprovare con altri ID di risorsa.
  • not_found significa che la risorsa non è disponibile per l’account.
Non usare una chiave di ingestione al posto di un token bearer dell’account. Non usare un token bearer dell’account al posto di una chiave di ingestione.

Proteggi i dettagli degli errori

  • Una risposta account_recovery_available contiene un recovery_token di breve durata. Tienilo nello stato protetto del client. Non inserirlo in log, URL, screenshot, segnalazioni al supporto o prompt per agenti.
  • I codici 500 usano sempre il messaggio Internal error. La risposta non indica il componente che ha generato l’errore. Non indovinare la causa.
  • Non aggiungere credenziali, diagnostica privata o dati dei clienti a un errore che mostri.
  • Una risposta dell’API non autorizza un acquisto, un’eliminazione o un’altra modifica all’account. Prima di queste azioni, ottieni l’approvazione dell’utente.

Esempi

Questi esempi mostrano la struttura dell’envelope. Il testo di error e next può essere diverso per ogni route.

Errore di convalida

Parametri di query non validi

JSON non valido

Valore del percorso non valido

Caricamento multipart non valido

Upgrade WebSocket non valido

Autenticazione non riuscita

Chiave di ingestione non valida

Questa risposta si applica all’ingestione della telemetria, non alle letture dell’account. La chiave deve appartenere al progetto indicato nella richiesta.

Risorsa non trovata

Accesso negato

Metodo non supportato

Timeout della richiesta

Conflitto di idempotenza

Limite di frequenza

Limite di utilizzo

Il testo di next e il valore di next_action cambiano a seconda che sia disponibile un cambio di piano. Se non lo è, next_action.code è wait_or_contact_support e il target è support.

Limite di spazio per gli artefatti

Recupero dell’account disponibile

Questa risposta aggiunge deleted_at e un recovery_token di breve durata. Tieni il token nello stato protetto del client.

Recupero dell’account scaduto

Organizzazione in pausa

Errore del server

storage_error, json_error e internal_error usano lo stesso messaggio error. I valori di code, next e next_action sono diversi.
Per endpoint, autenticazione e filtri, leggi l’API di telemetria.