Notification Dedup Key Mismatch Email Storm Automation: A Suppression List That Could Never Match

A deduplication check is, structurally, always a comparison between two things built by two different pieces of code at two different times: something computed fresh, right now, describing what's about to happen, and something reconstructed from a historical record describing what already did happen. The entire mechanism depends on both sides encoding the identical concept of sameness — the same fields, in the same order, formatted the same way — because a set membership check has no partial credit. A key that is one field short of matching isn't "almost the same notification" to a `Set.has()` call; it's simply a different string, indistinguishable from a notification that has never been sent at all.

The function building a notification's identity from a task, a notification type and a date is a genuinely reusable piece of logic — the SAME task, the SAME type, on the SAME day is a coherent, meaningful concept on its own, and reading just that function in isolation gives no indication anything is missing. The additional need to distinguish MULTIPLE recipients of the identical notification — an admin and the task's own assignee both receiving a due-today notice on the same day — was handled correctly at the point where new candidates are generated, by appending the recipient's email as a deliberate extra disambiguating field. That same appending step was never carried over to the code path reading the PERSISTED log back into a comparable set, because that second code path was written to reuse the base function directly rather than reproducing the exact same appending step done on the other side — two pieces of code, built to describe the identical concept, quietly diverging by exactly one field.

Centriu Vesper's scheduled notification engine works from a fixed table of moments in a task's lifecycle — a reminder the day before it's due, a charge notice at two points on the due day itself, and three escalating overdue warnings on each day afterward — evaluating every open, assigned task against that table on each scheduled run and producing a list of notifications that should fire right now. Before creating each candidate, the engine is meant to check whether that exact notification has already been sent, by comparing a freshly-built key against a set of keys reconstructed from its own persisted sent-notification log.

The freshly-built key, computed for each candidate about to be created, concatenated the task's identifier, the notification type, and the date, then appended the specific recipient's own email address as an explicit final component — a deliberate design choice, since a due-today notice genuinely goes to both the assignee and every admin as two separate, individually-trackable sends. The set built from the PERSISTED log, however, was constructed by applying only the base task-type-date function to each historical log entry, with no equivalent appending step — one field shorter than what the candidate side was checking for. A `Set` built from shorter keys can never satisfy a membership check built against longer ones; the comparison `sentKeys.has(fullKey)` was, for every single historical entry, comparing a string against a different string, and returning false every time regardless of how genuinely accurate the underlying sent-log actually was.

The fix is narrow and exact: the persisted-log side of the comparison now applies the identical recipient-email-appending step used on the candidate side, reading the recipient's email directly from the log entry's own already-stored `recipientEmail` field — no schema change and no new data required, since the log had been correctly recording that field all along; only the code reading it back into a comparable key had been built inconsistently with the code writing the check against it. With both sides of the comparison built the same way, a genuinely already-sent notification is now correctly recognized on every subsequent run, and the corresponding email is correctly skipped.

Before the fix, a task assigned to one person and left open past its due date would generate a due-today notice, correctly logged as sent. On the very next scheduled run, the engine would check its own log, fail to recognize that exact due-today notice as already sent because of the one-field key mismatch, and generate — and send — the identical notice again, logging a second, redundant entry. Every subsequent run would repeat the same pattern for every notification moment the task had already passed, compounding for as long as the task stayed open. After the fix, each of the task's six possible notification moments fires exactly once, correctly suppressed on every run after its first genuine send.

A task's assignee and any relevant admins now receive each of Centriu Vesper's scheduled reminder, due-today and overdue notifications exactly once per genuine occurrence, rather than repeatedly on every scheduled run for as long as the task remains open — closing a gap that scaled email volume directly with how long a task stayed unfinished, independent of whether anything about the task had actually changed.

This automation governs only the internal suppression logic deciding whether a given notification has already been sent — it does not change the notification schedule itself (which moments exist, at which hours, to which roles), and a workflow relying on receiving a reminder repeatedly on purpose would need a deliberately configured recurring notification, which is a different mechanism than this dedup check entirely.

Reusing a shared "base identity" function on both the candidate-generation side and the historical-log side looks, correctly, like the safer choice for keeping two comparisons in sync — shared code cannot drift the way two independently-written implementations can. The risk sits specifically in what happens AFTER that shared call: if one side appends an additional disambiguating field (here, the recipient's email, needed because a single notification type and day can genuinely go to more than one person) and the other side does not, the two paths silently stop describing the same concept, and no amount of the shared base function being correct changes that. The fix does not abandon the shared base function — it keeps it — but ensures the SAME additional step is applied consistently on both sides of the comparison, rather than only one.