Ao reimplantar, uma push já enviada foi enviada de novo — resolvendo envios duplicados de notificações no FCM

Organizei o incidente de envio duplicado de notificações push que enfrentei ao operar sozinho um app de previsão de surfe, e o processo de resolução.
Era uma funcionalidade comum que envia notificações aos usuários quando determinadas condições são atendidas, mas, sempre que o servidor era reimplantado,
o problema de reenviar "notificações já enviadas" se repetia.

■ Problema

• A mesma notificação era enviada em duplicidade a cada reimplantação/reinício
• Em local era difícil reproduzir, e acontecia apenas logo após o deploy, o que tornava complicado encontrar a causa

■ Causa

• O estado de prevenção de duplicidade (dedup) era mantido apenas na memória do servidor
• Ao reimplantar, um novo processo subia e esse estado era totalmente resetado → passava a ser tratado como "não enviado" e era reenviado

■ Solução

• Alterei a estrutura para repopular (seed-on-boot) as chaves de dedup a partir do DB na inicialização → o estado passa a ser mantido mesmo após reimplantações
• Também descobri que a abordagem de 'notificar apenas no momento em que a condição muda' deixava escapar mudanças de peso nesse intervalo
  → Migrei para uma abordagem de acumular os motivos e subir gradualmente o nível (escalation)
• Organizei os tokens FCM seguindo o princípio de 1 token por dispositivo (incluindo renovação de tokens e tratamento de tokens duplicados)

■ Lições

• Se um estado que "deve acontecer apenas uma vez", como dedup de notificações, ficar só em memória, cada deploy vira um bug
• O ciclo de vida do estado deve ser projetado com base em armazenamento persistente, não no processo
• Para triggers, julgar com base no 'estado atual' tende a perder menos casos do que se basear no 'momento de transição'

Um caso prático útil para quem trabalha com push/notificações no servidor, cron/batch e lógica de prevenção de duplicidade.