- Shipped
- August 6, 2026 at 11:36 PM UTC
- Author
- Kamo
- Commit
- 2e31839
Idempotency with NO schema change. The reminder bucket is a pure function of (dueDate, today) and never of "when we last sent", so the only durable state a notification needs is a per-(assignment, bucket, dueDate, channel) claim — and SET NX in the Redis DocsService already runs (WopiLockService, KSessionService) has exactly the semantics of the UNIQUE constraint the design asked a table for. It is atomic across the RollingUpdate replicas, the due date is IN the key so extending a due date legitimately restarts the ladder, and it leaves the sweep entirely READ-ONLY against CockroachDB: no write transaction is ever open while EmailService blocks on SMTP. Claim policy is at-most-once by default. An observed failure shortens the claim's TTL so the next tick retries; a crash between send and mark does NOT retry, because a missed reminder is recovered by the next bucket and a duplicate compliance email to every employee of every tenant is not recoverable at all. Redis being unreachable refuses the send rather than sending unclaimed. packageTitle and voidReason are HTML-escaped Java-side: TemplateRenderer is a flat regex replace with no escaping, so HR-authored prose otherwise reaches every employee's inbox as markup, sent from the org's own verified domain. Every varying sentence is pre-rendered as one whole-sentence variable because there are no conditionals and no pluralization either. Persistence is one seam (LegalNotificationRecorder) writing the Redis ledger plus one structured legal-notify line. The durable evidence table is REPORTED in the plan, not invented: a new shared-lib entity is a KamoInitializer run across every consumer.