Trieu la recuperació adequada
El mateix codi d’error descriu dues situacions diferents. Comproveuretryable abans
d’actuar; l’estat HTTP per si sol no indica si s’ha de tornar a intentar.
Dades d’entrada diferents
La sol·licitud encara s’està processant
Aquest exemple també inclou la capçalera de resposta HTTPRetry-After: 1.
Mantingueu estable la identitat del reintent
Per a les operacions que documenten la idempotència, la clau s’associa a l’organització, el compte de servei, el mètode HTTP, la ruta del recurs i la versió de l’API resolta. Si canvieu qualsevol d’aquests elements, es crea una identitat de reintent diferent; això no recupera l’operació original. Rotar una credencial dins del mateix compte de servei no canvia aquesta identitat, tot i que la credencial de substitució ha de tenir igualment els permisos necessaris. Quan us recupereu d’un temps d’espera esgotat, mantingueu la clau, el cos, la ruta i la versió originals. No genereu una clau nova només per superar un conflicte: és possible que l’escriptura original ja s’hagi completat. Recupereu el recurs quan en conegueu l’ID i seguiu el procediment de recuperació documentat de l’operació. Una reproducció completada inclouIdempotent-Replayed: true quan l’operació documenta la reproducció de respostes.
Enviar un Idempotency-Key no fa que una operació sigui idempotent, tret que la seva
referència admeti explícitament aquesta capçalera. La protecció davant de
reintents està limitada per la política de retenció de l’operació; no és una
garantia permanent contra duplicats.
Si el processament continua sense resoldre’s, contacteu amb Living Security Support
i indiqueu request_id, la marca de temps en UTC, el mètode, la ruta i la versió de
l’API. No hi incloeu mai cap clau d’API, secret de client ni testimoni d’accés.