Tentativas, desativação e reenvio
Quando o Vipter tenta de novo uma entrega que falhou, quando desativa o endpoint sozinho, o que acontece com os eventos enquanto ele está desligado e como usar o evento de teste e o reenvio do painel.
Cada endpoint recebe a sua própria entrega de cada evento. Uma entrega passa por estes status, que aparecem na coluna Status de Entregas recentes:
| Status | Significado |
|---|---|
pending | Na fila, esperando a primeira tentativa ou um reenvio. |
delivering | Sendo enviada agora. |
succeeded | O seu servidor respondeu 2xx em até 10 segundos. Status final. |
failed | A última tentativa falhou e há outra agendada. |
exhausted | As tentativas acabaram, ou o endpoint estava desativado. Status final, até um reenvio manual. |
O que conta como falha está em A resposta.
Calendário de tentativas
São até 8 tentativas por entrega. A primeira sai logo depois de o evento ser criado, em geral em menos de um minuto. Depois de cada falha, o Vipter espera:
| Tentativa | Espera depois da falha anterior | Tempo desde a primeira tentativa |
|---|---|---|
| 1 | 0 | |
| 2 | 1 minuto | 1 minuto |
| 3 | 5 minutos | 6 minutos |
| 4 | 30 minutos | 36 minutos |
| 5 | 2 horas | cerca de 2 h 36 min |
| 6 | 6 horas | cerca de 8 h 36 min |
| 7 | 24 horas | cerca de 32 h 36 min |
| 8 | 48 horas | cerca de 80 h 36 min |
As esperas são mínimas: a fila é processada a cada minuto, então cada tentativa pode sair um pouco depois. Se a oitava falhar, a entrega fica exhausted. Na prática, um endpoint que volta ao ar até cerca de 3 dias e 8 horas depois de uma falha ainda recebe o evento sozinho.
Cada tentativa leva o mesmo corpo, com o mesmo id e o mesmo created, e uma assinatura nova, com o t do momento do envio.
Desativação automática
O Vipter conta, por endpoint, as entregas seguidas que terminaram em exhausted. Quando a contagem chega a 20, o endpoint é desativado e o card dele mostra o motivo auto-disabled after 20 exhausted deliveries. Uma entrega com succeeded zera a contagem.
A contagem é de entregas esgotadas, não de tentativas: são 20 eventos que falharam 8 vezes cada. Um endpoint fora do ar só é desativado depois de passar pelo calendário inteiro de pelo menos 20 eventos.
Para ligar de novo, corrija o seu servidor e ative a chave Ativo do endpoint. Ligar a chave zera a contagem e apaga o motivo.
Eventos enquanto o endpoint está desativado
Vale tanto para a desativação automática quanto para a chave desligada à mão:
- Eventos novos não são guardados para ele. O endpoint só recebe entregas dos eventos criados enquanto está ativo. Um evento criado durante a desativação nunca chega a esse endpoint, nem depois de ligar de novo, e não há como reenviá-lo.
- Entregas que já estavam na fila são encerradas. Na vez delas, ficam
exhaustedcom o erroendpoint disabled, sem tentar enviar e sem contar para a desativação. Ligar o endpoint de novo não as retoma: use Reenviar em cada uma, com o endpoint já ativo.
O mesmo vale para um endpoint criado depois de um evento: ele não recebe eventos anteriores à sua criação.
Para conferir o que aconteceu no período, compare o seu sistema com as listas de pedidos, assinaturas e clientes do painel.
Reenviar uma entrega
Entregas recentes mostra as 50 entregas mais recentes da loja, de todos os endpoints. Toda linha que não está succeeded tem o botão Reenviar. Ao clicar:
- A entrega volta para
pendingcom as tentativas zeradas e é enviada na hora. - Aparece Entrega reenfileirada..
- Se falhar de novo, ela segue o calendário desde o início.
O reenvio manda o mesmo evento, com o mesmo id: o seu controle de idempotência trata como repetição se ele já tiver sido processado. A assinatura é calculada no momento do reenvio, com o segredo atual.
Não dá para reenviar uma entrega succeeded pelo painel. Reenviar para um endpoint desativado encerra a entrega na hora com endpoint disabled: ligue o endpoint antes.
Evento de teste
O botão Enviar evento de teste cria um evento customer.created novo, com um cliente fictício e "test": true em data.object. O formato está no catálogo.
- Ele vai para todos os endpoints ativos que recebem
customer.createdou todos os eventos, e só para esses. - É enviado na hora e aparece Evento de teste enfileirado.. Se falhar, segue o mesmo calendário de tentativas de um evento real e conta para a desativação automática.
- Cada clique cria um evento com um
idnovo. - Sem nenhum endpoint ativo, o botão fica desabilitado.
Remover um endpoint
Remover apaga o endpoint, o segredo e o histórico de entregas dele. As entregas pendentes param. Para trocar de URL sem perder eventos, crie o endpoint novo, confirme que ele recebe o evento de teste e só então remova o antigo. Nesse intervalo, os dois recebem os mesmos eventos, com o mesmo id.
O que fazer a seguir
- Veja como responder rápido para não gerar tentativas à toa.
- Troque o segredo sem perder eventos em Verificar a assinatura.
Verificar a assinatura
Como o Vipter assina cada webhook, código testado em Node.js, PHP e Python para conferir a assinatura, como trocar o segredo sem perder eventos e os erros que mais fazem a verificação falhar.
Parâmetros de URL do checkout
Referência técnica de cada parâmetro que o link de checkout aceita, com formato, validação, o que acontece com um valor inválido e como montar os links no seu código.