Elija la recuperación adecuada
El mismo código de error describe dos situaciones distintas. Comprueberetryable antes de
actuar; el estado HTTP por sí solo no indica si debe reintentar la solicitud.
Datos de entrada diferentes
Solicitud en procesamiento
Este ejemplo también incluye el encabezado de respuesta HTTPRetry-After: 1.
Mantenga estable la identidad de reintento
En las operaciones que documentan la idempotencia, la clave se limita al ámbito de la organización, la cuenta de servicio, el método HTTP, la ruta del recurso y la versión de API resuelta. Si cambia cualquiera de estos elementos, se crea una identidad de reintento distinta; esto no permite recuperar la operación original. Rotar una credencial de la misma cuenta de servicio no modifica esa identidad, aunque la credencial de reemplazo debe seguir contando con los permisos necesarios. Conserve la clave, el cuerpo, la ruta y la versión originales al recuperarse de un tiempo de espera agotado. No genere una clave nueva solo para superar un conflicto: es posible que la escritura original ya se haya realizado correctamente. Recupere el recurso cuando conozca su ID y utilice el procedimiento de recuperación documentado de la operación. Una repetición completada incluyeIdempotent-Replayed: true cuando la operación documenta la reproducción de la respuesta.
Enviar un encabezado Idempotency-Key no hace que una operación sea idempotente, a menos que su
referencia admita explícitamente ese encabezado. La protección frente a reintentos está limitada por la
política de retención de la operación; no es una garantía permanente contra duplicados.
Si el procesamiento sigue sin resolverse, póngase en contacto con Soporte de Living Security
e indique request_id, la marca de tiempo en UTC, el método, la ruta y la versión de API. No incluya nunca
una clave de API, un secreto de cliente ni un token de acceso.