Antwortcodes für Status

Die folgenden Statuscodes können in gRPC-Antworten zurückgegeben werden. Das trifft auf alle auf dieser Website dokumentierten gRPC-Versionen zu.

Code Status Hinweise
0 OK Rückgabe am Success
1 CANCELLED Der Vorgang wurde abgebrochen, üblicherweise vom Aufrufer.
2 UNKNOWN Dieser Fehler wird z. B. zurückgegeben, wenn ein von einem anderen Adressbereich erhaltener Statuswert zu einem Fehlerbereich gehört, der in diesem Adressbereich nicht bekannt ist. Auch Fehler, die von APIs ausgelöst werden, die nicht genügend Fehlerinformationen liefern, können in diesen Fehler umgewandelt werden.
3 INVALID_ARGUMENT Der Client hat ein ungültiges Argument angegeben.
4 DEADLINE_EXCEEDED Die Frist ist abgelaufen, bevor der Vorgang abgeschlossen wurde. Bei Vorgängen, die den Systemstatus verändern, kann dieser Fehler angezeigt werden, auch wenn der Vorgang erfolgreich abgeschlossen wurde. Zum Beispiel könnte eine erfolgreiche Antwort von einem Server so lange verzögert worden sein, dass die Frist abgelaufen ist.
5 NOT_FOUND Einige angeforderte Entitäten wurden nicht gefunden.
6 ALREADY_EXISTS Die Entität, die ein Client erstellen wollte, existiert bereits.
7 PERMISSION_DENIED Der Aufrufer hat keine Berechtigung zur Ausführung des angegebenen Vorgangs. Verwenden Sie PERMISSION_DENIED nicht für Ablehnungen, die durch erschöpfte Ressourcen verursacht werden. Verwenden Sie stattdessen RESOURCE_EXHAUSTED für diese Fehler. Verwenden Sie PERMISSION_DENIED nicht, wenn der Aufrufer nicht ermittelt werden kann (verwenden Sie stattdessen UNAUTHENTICATED für diese Fehler). Wenn Sie den Fehlercode PERMISSION_DENIED erhalten, bedeutet das nicht, dass die Anfrage gültig ist oder die angefragte Entität existiert oder andere Vorbedingungen erfüllt.
8 RESOURCE_EXHAUSTED Eine Ressource, z. B. ein nutzerbezogenes Kontingent, ist erschöpft oder der Speicherplatz für das gesamte Dateisystem ist ausgegangen.
9 FAILED_PRECONDITION Der Vorgang wurde abgelehnt, weil der Systemzustand nicht für die Ausführung des Vorgangs geeignet ist. Beispiel: Das zu löschende Verzeichnis ist nicht leer oder ein rmdir-Vorgang wird auf eine Ressource angewendet, die kein Verzeichnis ist.
10 ABORTED Der Vorgang wurde abgebrochen, in der Regel aufgrund eines Parallelitätsproblems wie einer fehlgeschlagenen Sequencer-Überprüfung oder einer abgebrochenen Transaktion.
11 OUT_OF_RANGE Beim Vorgang wurde versucht, den gültigen Bereich zu überschreiten.
12 UNIMPLEMENTED Dieser Vorgang ist nicht implementiert oder wird bei diesem Dienst nicht unterstützt bzw. nicht aktiviert.
13 INTERNAL Interne Fehler. Das bedeutet, dass einige Invarianten, die vom zugrunde liegenden System erwartet werden, nicht erfüllt wurden. Dieser Fehlercode ist schwerwiegenden Fehlern vorbehalten.
14 UNAVAILABLE Der Dienst ist derzeit nicht verfügbar. Dies ist höchstwahrscheinlich ein vorübergehender Zustand, der durch Wiederholen mit einem Backoff korrigiert werden kann.
15 DATA_LOSS Dauerhafter Datenverlust oder Datenkorruption.
16 UNAUTHENTICATED Die Anfrage enthält keine gültigen Authentifizierungsdaten für diesen Vorgang.

Manchmal können mehrere Fehlercodes zutreffen. Für Dienstleistungen sollte der spezifischste Fehlercode zurückgegeben werden. Beispiel: OUT_OF_RANGE sollte gegenüber FAILED_PRECONDITION bevorzugt werden, wenn beide Codes zutreffen. Entsprechend ist NOT_FOUND oder ALREADY_EXISTS gegenüber FAILED_PRECONDITION vorzuziehen.

"FAILED_PRECONDITION" vs. "ABORTED" vs. "UNAVAILABLE"

Im Folgenden finden Sie einen Lackmustest, der Ihnen bei der Entscheidung zwischen FAILED_PRECONDITION, ABORTED und UNAVAILABLE helfen kann:

  • Verwende UNAVAILABLE, wenn der Client nur den fehlgeschlagenen Aufruf wiederholen kann.
  • Verwenden Sie ABORTED, wenn der Client den Vorgang auf einer höheren Ebene wiederholen soll, z. B. wenn ein vom Kunden angegebener Test- und Set-Wert fehlschlägt. Dies bedeutet, dass der Client eine Read-Modify-Write-Sequenz startet.
  • Verwende FAILED_PRECONDITION, wenn der Client erst einen neuen Versuch starten soll, nachdem das Problem mit dem Systemzustand explizit behoben wurde. Wenn beispielsweise ein „rmdir“ fehlschlägt, weil das Verzeichnis nicht leer ist, sollten Sie am besten FAILED_PRECONDITION zurückgeben, da der Client den erneuten Versuch erst dann machen sollte, wenn die Dateien aus dem Verzeichnis gelöscht wurden.

"INVALID_ARGUMENT" vs. "FAILED_PRECONDITION" vs. "OUT_OF_RANGE"

Im Folgenden finden Sie einen Lackmustest, der Ihnen bei der Entscheidung zwischen INVALID_ARGUMENT, FAILED_PRECONDITION und OUT_OF_RANGE helfen kann:

  • Verwende INVALID_ARGUMENT, wenn die Argumente unabhängig vom Systemzustand problematisch sind. Beispiel: Eine fehlerhafte URL
  • Verwende OUT_OF_RANGE, wenn ein Wert aufgrund des Systemzustands außerhalb des zulässigen Bereichs liegt. Beispiel: Das Startdatum liegt vor dem start_date_restrict.
  • Verwende FAILED_PRECONDITION, wenn der Wert aufgrund des Systemzustands ungültig ist, aber kein OUT_OF_RANGE-Wert ist.