Escolha a recuperação adequada
O mesmo código de erro descreve duas situações distintas. 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 estável a identidade de repetição
Para as operações que documentam idempotência, a chave tem como escopo a organização, a conta de serviço, o método HTTP, o caminho do recurso e a versão da API resolvida. A alteração de qualquer um desses elementos cria uma identidade de repetição diferente e 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 sucesso. Recupere o recurso quando o respectivo ID for conhecido e utilize o procedimento de recuperação documentado da operação. Uma reprodução concluída incluiIdempotent-Replayed: true quando a operação documenta a reprodução de resposta.
O envio de Idempotency-Key não torna uma operação idempotente, a menos que a
respectiva referência ofereça suporte explícito a esse cabeçalho. A proteção contra repetição é limitada pela
política de retenção da operação; não constitui uma garantia permanente contra duplicidades.
Se o processamento permanecer sem solução, entre em contato com o Suporte da Living Security
informando request_id, o carimbo de data e hora em UTC, o método, o caminho e a versão da API. Nunca inclua
uma chave de API, um segredo de cliente nem um token de acesso.