Files
TREK/server/tests/unit
Maurice c04fca81ee fix(notifications): claim a reminder before sending it, give it back when sending fails
The trip and todo reminder ticks sent with `.catch(() => {})` and then
marked the reminder sent whatever happened. A send that threw (a DB error
resolving the recipients) or whose every channel failed (SMTP down, no
in-app) was recorded as delivered and never retried, without a log line.
And because the mark came after the send, two processes running the same
tick (a rolling update overlap, a stray container on the same volume)
both sent.

Each reminder is now claimed first with one conditional UPDATE through
its repository: reminder_sent_for is set only while it differs from the
start date (and the start date is still the one read), reminded_at only
while it is empty or older than the 20 hour dedup window. Only the
process whose update lands sends. If the send throws, or it attempted
in-app and channels and none went out, the claim is given back, the
failure is logged, and the next tick tries again until the trip starts
or the todo falls out of its window. A send nobody wanted (everyone
opted out) stays marked, since a retry would reach no one.

For that, NotificationsService.send() now reports what it attempted and
what was delivered; a channel that rejects or answers false counts as
not delivered. Existing callers ignore the result.
2026-10-08 13:02:57 +02:00
..
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-10-06 19:27:30 +02:00
2026-06-16 22:22:45 +02:00
2026-10-06 19:27:30 +02:00