Volleyball Elite Academy development update

Volleyball Elite Academy Stop the weekly digest from re-sending on every restart Stop the weekly digest from re-sending on every restart Volleyball Elite Academy — Development Update • May 24, 2026 --- title: Stop the weekly digest from re-sending on every restart --- Stop the weekly digest from re-sending on every restart What & Why The "Weekly Academy Digest" is supposed to send once a week, on Monday morning between 08:00 and 10:00 server local time. Today a SuperAdmin received the identical digest 8 times in ~2 hours (alternating between the two SuperAdmin recipients on each tick), because the only thing preventing repeat sends is an in-memory variable () inside in . Every time the server process restarts during the Monday 08:00–10:00 window — common during deploys, dev hot-restarts, or any crash — that variable resets to , the scheduler re-evaluates the window, and the digest fires again to every SuperAdmin. Other digests in the same file (the conversation inbox digest at ~line 1236, the Resend webhook health alert at ~line 1880) already protect against this with a database-backed dedupe — they query for a recent row keyed by the period before sending. The weekly digest just never got that treatment. Done looks like During the Monday 08:00–10:00 send window, each SuperAdmin receives the Weekly Academy Digest exactly once, even if the server restarts 10 times inside that window. The dedupe survives process restarts (i.e. is database-backed, not in-memory only). An admin reading the SuperAdmin "Email log" can see one row per SuperAdmin per ISO-week for the weekly digest. A backend test pins the behaviour: simulate two ticks of for the same Monday with the in-memory flag wiped between them (mirroring a restart) and assert that the second tick sends zero emails. An e2e or unit test pins that two SuperAdmins both get exactly one digest each on the first tick of a Monday window. Out of scope Changing the digest contents, recipient selection, or window times. Migrating the other already-deduped digests (they're fine). Adding a UI to manually re-send the digest. Steps 1. Pick a stable period key — Decide on an ISO-week-style key (e.g. or ) to use as the dedupe identity in . Choose whichever shape matches the existing log query helpers used by the conversation digest. 2. Add the per-recipient pre-send check — Inside , before sending to a SuperAdmin, query for an existing row with that period key + recipient in the last 7 days. If found, skip the send (and skip the in-app fan-out so the in-app card isn't double-created either). 3. Write the dedupe row atomically with the send — Use the same email-log write path the other digests use so the row is committed in the same transaction/sequence as the actual Resend call, not a best-effort afterwards. 4. Keep the in-memory as a soft fast-path — It still avoids hammering the database every tick on the same process, but the database check is now the source of truth. 5. Tests — Add a server test that simulates two ticks for the same Monday (clearing the in-memory guard between them) and asserts only one Resend send per recipient. Add a second test for the multi-recipient case (one SuperAdmin already sent, second SuperAdmin not yet) so the per-recipient granularity is pinned. 6. Manual verification note — In the task notes, record the SQL the executor can run after deploy to confirm exactly one row per SuperAdmin per ISO-week for the weekly digest going forward. Relevant files - - - - - - - Volleyball Elite Academy Reply to this email — we read every reply. You received this because you have an account with Volleyball Elite Academy. elitevolleyball.training