Das richtige Vorgehen zur Behebung wählen
Derselbe Fehlercode beschreibt zwei unterschiedliche Situationen. Prüfen Sieretryable, bevor
Sie handeln; der HTTP-Status allein zeigt nicht an, ob Sie die Anfrage wiederholen sollten.
Abweichende Eingaben
Anfrage wird noch verarbeitet
Dieses Beispiel enthält zusätzlich den HTTP-Antwort-HeaderRetry-After: 1.
Die Wiederholungsidentität stabil halten
Bei Vorgängen, für die Idempotenz dokumentiert ist, gilt der Key jeweils für die Organisation, das Service-Konto, die HTTP-Methode, den Ressourcenpfad und die aufgelöste API-Version. Ändert sich einer dieser Werte, entsteht eine andere Wiederholungsidentität; der ursprüngliche Vorgang wird dadurch nicht wiederhergestellt. Das Rotieren einer Anmeldedaten-Zuordnung unter demselben Service-Konto ändert diese Identität nicht, allerdings muss die neue Anmeldeinformation weiterhin über die erforderliche Berechtigung verfügen. Behalten Sie bei der Wiederherstellung nach einem Timeout den ursprünglichen Key, Body, Pfad und die Version bei. Erzeugen Sie nicht einfach einen neuen Key, nur um einen Konflikt zu umgehen: Der ursprüngliche Schreibvorgang war möglicherweise bereits erfolgreich. Rufen Sie die Ressource ab, sofern ihre ID bekannt ist, und nutzen Sie das dokumentierte Wiederherstellungsverfahren des Vorgangs. Eine abgeschlossene Wiederholung enthältIdempotent-Replayed: true, sofern der Vorgang die erneute Wiedergabe von Antworten dokumentiert.
Das Senden von Idempotency-Key macht einen Vorgang nicht idempotent, es sei denn, dessen
Referenz unterstützt diesen Header ausdrücklich. Der Schutz vor Wiederholungen ist durch die
Aufbewahrungsrichtlinie des Vorgangs begrenzt; er ist keine dauerhafte Garantie gegen Duplikate.
Wenn die Verarbeitung ungeklärt bleibt, wenden Sie sich an den Living Security Support
und geben Sie request_id, UTC-Zeitstempel, Methode, Pfad und API-Version an. Geben Sie niemals
einen API-Key, ein Client Secret oder ein Zugriffstoken an.