Nach dem erneuten Deployment wurde eine bereits gesendete Push-Nachricht erneut verschickt — doppelte FCM-Benachrichtigungen beheben

Ich habe einen Vorfall mit doppelt versendeten Push-Benachrichtigungen und den Lösungsweg zusammengefasst, den ich beim Betrieb einer Surfvorhersage-App als Solo-Entwickler erlebt habe.
Es handelt sich um eine gängige Funktion, bei der Nutzer benachrichtigt werden, wenn bestimmte Bedingungen erfüllt sind. Doch bei jedem erneuten Deployment des Servers trat wiederholt das Problem auf, dass
„bereits gesendete Benachrichtigungen“ erneut verschickt wurden.

■ Problem

• Bei jedem erneuten Deployment/Neustart wurde dieselbe Benachrichtigung doppelt versendet
• Lokal ließ es sich kaum reproduzieren, und da es nur direkt nach dem Deployment auftrat, war die Ursachenfindung schwierig

■ Ursache

• Der Zustand zur Duplikatvermeidung (Dedup) wurde nur im Serverspeicher gehalten
• Beim erneuten Deployment startete ein neuer Prozess, wodurch dieser Zustand komplett zurückgesetzt wurde → es galt als „noch nicht gesendet“ und wurde erneut versendet

■ Lösung

• Die Struktur wurde so geändert, dass der Dedup-Key beim Booten wieder aus der DB befüllt wird (seed-on-boot) → der Zustand bleibt auch über Deployments hinweg erhalten
• Dabei fiel außerdem auf, dass der Ansatz „Benachrichtigung nur im Moment, in dem sich die Bedingung ändert“ zwischenzeitliche Gewichtungsänderungen verpasste
  → Umstellung auf einen Ansatz, bei dem Gründe gesammelt und stufenweise erhöht werden (Eskalation)
• FCM-Token wurden nach dem Prinzip „1 Gerät, 1 Token“ bereinigt (einschließlich Token-Erneuerung und Behandlung doppelter Token)

■ Erkenntnisse

• Wenn ein Zustand, der „nur einmal auftreten darf“, wie Benachrichtigungs-Dedup, nur in Memory gehalten wird, wird jedes Deployment zum Bug
• Der Lebenszyklus von Zustand sollte nicht am Prozess, sondern an einem persistenten Speicher ausgerichtet entworfen werden
• Bei Triggern ist es weniger fehleranfällig, auf Basis des „aktuellen Zustands“ zu entscheiden statt anhand des „Übergangszeitpunkts“

Ein praxisnaher Fall für alle, die mit Server-Push/Benachrichtigungen, Cron-/Batch-Jobs und Logik zur Duplikatvermeidung arbeiten.