Wann du es brauchst
Das Produkt braucht eine Erinnerung zu einem anderen Zeitpunkt als den vorhandenen (24 Stunden und 2 Stunden vor dem Termin), zum Beispiel 7 Tage vorher.
Regeln, die gelten bleiben
- Die Erinnerungslogik ist rein und liegt in
src/lib/booking/reminders.ts; der Cron-Workflow lädt nur Daten und stellt zu. - Eine Zustellung wird in
reminder_deliveriesreserviert, bevor die E-Mail versendet wird: nie zuerst senden und danach eintragen. - Nach einer Umbuchung ändert sich die
revisionder Buchung und die Erinnerungen werden erneut fällig.reminderKeynicht umgehen.
Schritte
- Füge das neue Fenster zu
reminderKindsinsrc/lib/booking/reminders.tshinzu. Halte die Liste vom entferntesten zum nächsten Fenster sortiert: Stand der Cron still, sendetdueRemindersnur den letzten passenden Eintrag, also den nächsten. Für eine Woche vorher kommt{ kind: "7d", minutesBefore: 7 * 24 * 60 }an den Anfang. ReminderKindwird aus der Liste abgeleitet, daher verlangt TypeScript nun einen Betreff inreminderSubjects(src/lib/booking/workflows.ts). Schreibe ihn in der Sprache des Produkts.- In
sendDueReminderslädt die Abfrage nur Buchungen, die innerhalb von24 * 60 + 1Minuten beginnen. Ersetze den festen Wert durch das größteminutesBeforeausreminderKindsplus eine Minute, sonst wird das neue Fenster nie erreicht. - Eine Migration ist nicht nötig:
reminder_deliveries.kindist Text und der Primärschlüssel(booking_id, kind, revision)macht jede neue Art bereits idempotent. - Ergänze Tests in
test/notifications.test.tsfür das neue Fenster:- es wird fällig, sobald die Buchung das Fenster erreicht;
- eine innerhalb des Fensters angelegte Buchung erhält es nicht;
- bei stillstehendem Cron wird nur die nächste Erinnerung gesendet;
- eine neue
revisionmacht sie erneut fällig.
Fertig, wenn
- die Prüfbefehle erfolgreich laufen;
- die neuen Tests die vier genannten Fälle abdecken;
sendDueReminderskein fest eingetragenes Fenster mehr enthält.
