Retries e recuperação de falhas
Quando repetir, quando não repetir e como preservar idempotência.
Atualizado em 01/09/2026
| Situação | Ação recomendada |
|---|---|
| GET com timeout/erro transitório | Retry com backoff e jitter |
| Mutação com resultado desconhecido | Retry da mesma chamada com a mesma Idempotency-Key |
| 429 RATE_LIMIT_EXCEEDED | Aguardar Retry-After; depois backoff |
| 503 RATE_LIMIT_STORE_UNAVAILABLE | Aguardar Retry-After; depois backoff |
| 409 IDEMPOTENCY_REQUEST_IN_PROGRESS | Aguardar Retry-After e repetir exatamente a mesma chamada |
| 409 SLOT_UNAVAILABLE | Não repetir o mesmo horário; consultar availability novamente |
| 401/403 | Corrigir token, entitlement, scope ou allowlist; não fazer retry cego |
Importante: Nunca transforme timeout em uma nova operação lógica sem antes resolver a Idempotency-Key original. Isso evita appointments duplicados quando o servidor concluiu a primeira chamada mas a resposta se perdeu na rede.