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ückflug am Success
1	CANCELLED	Der Vorgang wurde abgebrochen, üblicherweise vom Aufrufer.
2	UNKNOWN	Dieser Fehler wird beispielsweise 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 zurückgeben, 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 ändern, kann dieser Fehler zurückgegeben werden, auch wenn der Vorgang erfolgreich abgeschlossen wurde. Zum Beispiel eine erfolgreiche Antwort von einem Server, die so lange verzögert wurde, dass die Frist abgelaufen ist.
5	NOT_FOUND	Ein angefordertes Element wurde nicht gefunden.
6	ALREADY_EXISTS	Die Entität, die ein Client erstellen wollte, existiert bereits.
7	PERMISSION_DENIED	Der Aufrufer ist nicht berechtigt, den angegebenen Vorgang auszuführen. Verwende PERMISSION_DENIED nicht für Ablehnungen, die dadurch verursacht werden, dass eine Ressource erschöpft ist. Verwende stattdessen RESOURCE_EXHAUSTED für diese Fehler. Verwende PERMISSION_DENIED nicht, wenn der Aufrufer nicht identifiziert werden kann. Verwende stattdessen UNAUTHENTICATED für diese Fehler. Der Erhalt des Fehlercodes PERMISSION_DENIED bedeutet nicht, dass die Anfrage gültig ist oder die angeforderte 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. Beispielsweise ist das zu löschende Verzeichnis nicht leer oder ein rmdir-Vorgang wird auf ein anderes Verzeichnis angewendet.
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 korrigiert werden kann, wenn der Versuch mit einem Backoff wiederholt wird.
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 sollten Sie NOT_FOUND oder ALREADY_EXISTS gegenüber FAILED_PRECONDITION vorziehen.

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

Der folgende Lackmus-Test kann Ihnen bei der Entscheidung zwischen FAILED_PRECONDITION, ABORTED und UNAVAILABLE helfen:

• Verwenden Sie 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 Client angegebenes Test-and-Set fehlschlägt. Dies bedeutet, dass der Client eine Read-Modify-Write-Sequenz neu starten sollte.
• Verwenden Sie FAILED_PRECONDITION, wenn der Client es erst dann noch einmal versuchen soll, wenn der Systemstatus explizit korrigiert wurde. Wenn beispielsweise ein „rmdir“ fehlschlägt, weil das Verzeichnis nicht leer ist, sollte FAILED_PRECONDITION zurückgegeben werden. Der Client sollte den Vorgang dann erst wiederholen, wenn die Dateien aus dem Verzeichnis gelöscht wurden.

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

Der folgende Lackmus-Test kann Ihnen bei der Entscheidung zwischen INVALID_ARGUMENT, FAILED_PRECONDITION und OUT_OF_RANGE helfen:

• Verwenden Sie INVALID_ARGUMENT, wenn die Argumente unabhängig vom Systemstatus problematisch sind. Beispiel: fehlerhafte URL
• Verwenden Sie OUT_OF_RANGE, wenn ein Wert aufgrund des Systemzustands außerhalb des Bereichs liegt. Das start_date liegt beispielsweise vor dem start_date_restrict.
• Verwenden Sie FAILED_PRECONDITION, wenn der Wert aufgrund des Systemstatus ungültig ist, es sich aber nicht um einen OUT_OF_RANGE-Wert handelt.