Ler webhooks sem fazer tudo duas vezes

Todo sistema de webhook do mundo entrega pelo menos uma vez, e todo mundo se surpreende na primeira vez. O evento chega duas vezes, o cliente recebe mensagem duas vezes, e o relato de bug diz que o webhook está quebrado. Não está: está fazendo exatamente o que prometeu.

Por que uma repetição é normal

• Seu handler foi lento, então o remetente desistiu de esperar e tentou de novo.
• Seu handler respondeu 500 depois de fazer o trabalho.
• A conexão caiu depois de você responder, mas antes de a resposta chegar.
• Um deploy reiniciou o processo no meio da requisição.

Só uma dessas é um bug no seu código, e todas as quatro produzem um duplicado.

A correção é uma restrição de unicidade

CREATE TABLE handled (
  event_id TEXT PRIMARY KEY,
  handled_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Insira antes de agir. Se a inserção entrar em conflito, alguém já cuidou e você terminou. Isso sobrevive ao reinício no meio do caminho que um conjunto em memória não sobrevive, e não precisa de biblioteca, nem de lock, nem de coordenação entre workers.

Duas coisas que as pessoas erram depois disso

Elas respondem 200 depois do trabalho em vez de antes, o que transforma um handler lento num repetido. E verificam a assinatura depois de ler o corpo, o que significa que já interpretaram entrada de quem quer que tenha encontrado a URL. Assinatura primeiro, 200 em segundo, trabalho em terceiro.

Perguntas frequentes