Docs Webhook Overview Debuggando Problemas
Hoje o iFood não tem ferramentas externas para troubleshooting para uso das integrações. Temos apenas ferramentas internas para auditoria da entrega dos eventos. Temos dados sobre a entrada do evento na plataforma e das tentativas de entrega do evento para a integração. Se necessário, abrir um ticket para que possamos auxiliar no processo de debug. Está no nosso roadmap externalizar essa ferramenta.Erros comuns
Alguns erros que já ajudamos outras integrações a depurar.Validação de assinatura
A assinatura é feita em cima do byte array do payload enviado na request, e é esse byte array que deve ser utilizado para validar a assinatura, sem nenhum tipo de transformação no payload antes.É comum que algumas bibliotecas de web servers façam algum tipo de parse da informação antes de disponibilizar a informação no entrypoint da request da sua aplicação. Como estamos lidando com JSONs,{"prop1": "value1", "prop2": "value2"} é equivalente a {"prop2": "value2", "prop1": "value1"} para os parsers/encoders, mas o byte array formado pelos dois objetos são diferentes. Também é possível que alguns caracteres sejam encodados de maneiras diferentes dependendo da biblioteca ou linguagem sendo utilizada.Além disso, ao fazer o parse da informação para uma estrutura, é possível que o parse venha falhar em algum momento se campos forem adicionados no evento, pois faltaria informação na hora de gerar o byte array.É por isso que é necessário que o byte array seja tratado "as-is".Recebimento de mensagens duplicadas
É possível que enviemos mensagens mais de uma vez por problemas em nossa infraestrutura, mas isso não é algo recorrente, e entregas duplicadas recorrentes indicam um problema no lado da integração. O cenário mais comum que encontramos para mensagens duplicadas é o de timeouts.De qualquer maneira, utilize o campoid do evento para deduplicação dos eventos.Timeouts
Evite timeouts colocando a mensagem em uma fila para ser processada assíncronamente, respondendo a request assim que possível. A maioria dos servidores web já tem mecanismos implementados para identificar quando uma request foi cancelada/quando o servidor percebe que o client não está mais esperando pelo resultado da request. Se você identificar muitas requests que foram respondidas com sucesso pelo seu serviço, e mesmo assim estão recebendo muitos eventos duplicados, verifique o tempo de resposta dessas requests e se o servidor está processando este cancelamento da request corretamente.Nota: em caso de timeout nós não temos o código de resposta do seu servidor, porque a request é literalmente descartada no meio do processamento. Em tickets, indicar que as requests foram respondidas com202 só é relevante se o tempo de processamento da request estiver dentro dos 5 segundos de timeout.