Volleyball Elite Academy development update

Volleyball Elite Academy Admin Send-Test-Email Pipeline Verifier Admin Send-Test-Email Pipeline Verifier Volleyball Elite Academy — Development Update • April 28, 2026 Admin Send-Test-Email Pipeline Verifier What & Why Add a "Send Test Email" panel to the Communication Hub so a SuperAdmin can send a real Resend email to themselves (or any address) and watch the resulting webhook events arrive in real time. Today the only pipeline-verification tool is the existing webhook-health "Send test event" button, which posts a synthetic svix-signed payload to our own over localhost — it confirms the receiver works but bypasses Resend entirely. So when Resend isn't actually firing webhooks (the current 8-sent / 0-events alert), the synthetic test still says "OK" and the admin has no quick way to prove or disprove the round-trip without waiting for a real reminder to fire. This panel closes that gap: one button, real send through Resend, live timeline of → → events as they arrive on our webhook, with a clear "no events received in 60s" terminal state when the pipeline is genuinely broken. Done looks like A "Send Test Email" panel sits next to the existing webhook-health banner on the Communication Hub. Field is pre-filled with the logged-in admin's email; admin can edit it. Clicking "Send" delivers a real, minimal email via Resend (subject and body clearly mark it as a pipeline test, with a timestamp so multiple tests are distinguishable in the inbox). The send is logged in with a dedicated email type. Immediately after send the panel shows a live timeline: - "Sent to Resend" (checked, with the resend message id) - "email.sent webhook received" (pending → checked when event arrives) - "email.delivered webhook received" (pending → checked when event arrives) - "email.opened webhook received" (pending → checked if/when admin opens the message in their inbox; never required to terminate) The panel polls every ~2s for up to 60s. When , , or arrives, polling stops and the final state is shown. If 60s elapses with no events, polling stops and the panel surfaces "No webhook events received in 60s — your endpoint or signing secret is likely the problem" with a one-line pointer to the existing webhook-health diagnosis steps. A small "Recent test sends" list under the panel shows the last 5 pipeline tests with their final status, so admins can see a history without leaving the page. Per-admin rate limit: max 5 test sends per admin per hour. Limit overage returns a clear toast; does not consume webhook health budget. The new email type is registered in so it appears in the email-types directory and is excluded from production aggregate stats where appropriate. Out of scope Replacing or modifying the existing webhook-health "Send test event" button (synthetic round-trip). Both buttons coexist — they answer different questions. Sending tests from non-SuperAdmin roles. SuperAdmin only. Bulk test sends, scheduled tests, or recipient lists. Single recipient per click. Detecting / acting on for non-test emails. Any change to the existing table or the family-portal recap-test flow. Steps 1. New email type + catalog entry — Register in the email catalog with a clear description, sender address matching the dominant production sender, and any flags that exclude it from aggregate stats. Document that it is admin-triggered and not user-facing. 2. Backend: send endpoint — Add a SuperAdmin-only POST that validates the recipient email, enforces the 5-per-hour-per-admin rate limit (count rows where AND within the hour, behind a per-admin Postgres advisory lock to match the existing test-recap-email pattern), sends through so the row gets a and feeds the normal webhook plumbing, and returns . 3. Backend: events endpoint — Add a SuperAdmin-only GET keyed by that returns the email's current plus its full rows ordered by . Reuse this for both the live polling view and the "Recent test sends" history (history endpoint can be a separate thin GET that returns the last 5 rows with their latest event summary). 4. Frontend: panel UI — Add the panel to the Communication Hub page near the webhook-health banner. Use shadcn primitives matching the surrounding page. Form: email input pre-filled from the session's admin email, Send button. After send, render the four-row live timeline with check / pending / failed states, a 60s countdown, and the resend message id as small monospace text. Use TanStack Query with a polling refetchInterval that stops on terminal status or after 60s. 5. Frontend: recent history — Below the live panel, render the last 5 test sends as a compact list (recipient, sent-at, final state, opened?). Refresh on each new send. 6. Tests — Vitest for: rate-limit (sixth send in same hour rejected, sixth send by a different admin allowed, advisory-lock prevents two concurrent sends from both succeeding when at the cap), recipient validation (rejects non-email strings), and that the events endpoint returns rows in order. RTL test for the panel: starting state, transition to "sent" on mutation success, transition to "delivered" when the polled events response includes a delivered event, "no events received" terminal state when 60s elapses with the polled response staying empty. 7. Docs — Update to note the new admin tool and what failure mode it diagnoses (the gap between synthetic-receiver test and real Resend round-trip). Architectural constraints: Reuse the existing wrapper and the existing ingestion. Do not introduce a parallel send path or a separate events table. Do not add a new database table. Reuse + ; the rate limit is a count query, not a new ledger. Keep the from-address consistent with production () so the test exercises the same DKIM/SPF path real emails use. Do not introduce a third sender domain. The new endpoints must require SuperAdmin (use exactly like the surrounding routes in ). 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