ReboundEvento, ocorrência e tentativa
| Campo | Regra | Descrição |
|---|---|---|
| fingerprint | Grupo de erros | Agrupa falhas semelhantes dentro do projeto. |
| eventId | Uma captura | UUID v4 novo para cada ocorrência real. Reutilizado nos reenvios dela. |
| Tentativa HTTP | Entrega | Pode ser repetida se a resposta se perder. Não representa necessariamente uma nova ocorrência. |
Por que sete dias?
O Rebound mantém o comprovante de uma captura aceita por sete dias. Reenviar o mesmo eventId e conteúdo nesse prazo devolve a confirmação sem outra ocorrência, consumo ou excedente. A proteção é por projeto.
Se a falha acontecer novamente amanhã, gere outro eventId: o mesmo evento ganha uma nova ocorrência, com novo horário e consumo. Os sete dias não são a retenção do evento. Depois desse prazo, a deduplicação da captura antiga não é garantida. Sem eventId, não há essa garantia.
Política de reenvios
O SDK reenvia falhas de transporte e HTTP 408, 425, 429 e 5xx, com espera exponencial, variação aleatória e suporte a Retry-After. Há limites de tentativas, idade e capacidade. Um 2xx sem confirmação válida não conta como entrega.
Em uma integração HTTP própria, implemente esses controles. Não reenvie indefinidamente erros 400, 401 ou 409. Trate o bloqueio 403 de franquia conforme o corpo da resposta, em vez de iniciar um loop de retries.
Kubernetes e múltiplos pods
Em aplicações com várias réplicas, mantenha o eventId e o corpo da captura caso transfira uma tentativa de entrega entre workers ou pods. A proteção contra reenvios é por projeto e não depende de manter a conexão com o mesmo servidor da API.
Cada instância do SDK possui fila em memória. Aguarde close no encerramento e reserve tempo no desligamento do pod. OOM, SIGKILL e crashes podem perder capturas pendentes. Dois pods do cliente capturando separadamente recebem identidades distintas; o SDK não deduplica automaticamente a operação de negócio.