Escolha a recuperação adequada
O mesmo código de erro descreve duas situações diferentes. Verifiqueretryable antes de
agir; o status HTTP, por si só, não indica se é necessário tentar novamente.
Dados de entrada diferentes
Solicitação ainda em processamento
Este exemplo também inclui o cabeçalho de resposta HTTPRetry-After: 1.
Mantenha a identidade de repetição estável
Para operações que documentam idempotência, a chave tem escopo definido pela organização, conta de serviço, método HTTP, caminho do recurso e versão da API resolvida. Alterar qualquer um desses elementos cria uma identidade de repetição diferente; isso não recupera a operação original. A rotação de uma credencial na mesma conta de serviço não altera essa identidade, embora a credencial substituta ainda precise ter permissão. Mantenha a chave, o corpo, o caminho e a versão originais ao se recuperar de um timeout. Não gere uma nova chave apenas para contornar um conflito: a gravação original pode já ter sido concluída com êxito. Recupere o recurso quando o respectivo ID for conhecido e use o procedimento de recuperação documentado da operação. Uma reprodução concluída trazIdempotent-Replayed: true nas operações que documentam a reprodução de respostas.
Enviar um Idempotency-Key não torna uma operação idempotente, a menos que a
referência dela ofereça suporte explícito a esse cabeçalho. A proteção contra repetições é limitada pela
política de retenção da operação; ela não é uma garantia permanente contra duplicidades.
Se o processamento continuar sem solução, entre em contato com o Suporte da Living Security
informando request_id, carimbo de data e hora em UTC, método, caminho e versão da API. Nunca inclua
uma chave de API, um segredo do cliente ou um token de acesso.