Email retry/failure backstop gap (pre-existing, exposed by PLUTO-38 cron-drop): after dropping the dead drain-email-outbox cron, Pluto has NO email retry and NO failure alert. A failed send (SMTP timeout) strands the row 'pending' forever — no retry, no operator alert (the alert-after-5-attempts only ever fired from the now-dead drain, which never functioned anyway). Invisible today (0 pending). Live happy-path = Next.js after()-hook send. Restore options: (a) pg_net+pg_cron */5 GATED drain (sanctioned path; vercel.json CANNOT host sub-daily cron — fails the whole build); (b) external scheduler; (c) minimum cheap win = alert-on-strand observability (appEvents warn when a row sits pending > N min). Disposition: reliability vs cron-cost — Elazar's call. Not urgent.

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2026-06-14
• wi-cli-venus statusChanged · 6w ago
  Reframe: RE-ENABLE not build. emailOutbox table+enqueueEmail+drain code all live (PLUTO-11 ex-Mars); drain pg_cron DROPPED in migration 030 (pg_net absent). 5 real emails stuck pending since Jun18/24 (Timeout, attempt=1, never retried). DB LEG (migration 049, held for audit ping + mars secret pattern): CREATE EXTENSION pg_net + cron.schedule pluto-drain-email-outbox */5 net.http_get→/api/cron/drain-email-outbox, Bearer CRON_SECRET secret-safe via Supabase Vault (not inlined), idempotent unschedule-then-schedule. 5 stuck rows auto-drain first run. Paired with PLUTO-161 coder leg.
• wi-cli-venus commented · 6w ago
  049 audit PASS-to-apply (cron_auth_header + REVOKE-FROM-PUBLIC hardening + search_path pin). All 5 pre-apply checks evidenced (pg_net 0.20.0 available/installable, route Bearer-validated, idempotent, txn-safe). Apply-go GRANTED gated on hard apply-time condition: Vault cron_secret MUST be byte-equal to live Vercel CRON_SECRET (else every drain 401s forever) + smoke-test curl→200 before trusting tick. Applies independently of 161 code leg; drains 5 stuck-since-June rows.
• wi-cli-venus completed · 6w ago
  DONE — email-outbox drain backstop LIVE in prod. Migration 049 applied (db-pluto): CREATE EXTENSION pg_net 0.20.0, cron_auth_header() SECDEF helper (Bearer from vault.decrypted_secrets, three-way REVOKE → proacl=postgres+service_role only, search_path pinned, qualified vault lookup — Mars MARS-380 fleet-canonical), pg_cron 'pluto-drain-email-outbox' jobid 10 */5. End-to-end verified: fired the exact cron command (Vault→cron_auth_header()→net.http_get) → status 200 {ok:true}. Vault CRON_SECRET==prod-Vercel proven empirically (candidate→live drain 200) before scheduling → zero 401 noise. The drain reclaims stuck 'sending' + retries due 'pending' w/ exp backoff, dead-letters at maxAttempts. Bonus: the 5 emails stuck since June drained on smoke-test (sent=5). Pairs with PLUTO-161's enqueue-on-failure — together = at-least-once durable alert delivery.