Sandbox sender: claim daily cap tokens once when SES throttles a send #278

Activity

1. Silthus

   added a parent issue on Oct 5, 2026

   • Map: let teams send a first email before verifying their domain #225
2. Silthus

   added

   wayfinder:implement

   on Oct 5, 2026
3. Silthus

   self-assigned this

   on Oct 5, 2026
4. Silthus commented on Oct 5, 2026

   

   Silthus

   on Oct 5, 2026

   OwnerAuthor

   More actions

   Started by ticket worker impl-278-281 (Claude Opus 5.5 lane owner; GPT-6.1 Sol via Codex for review lanes, Claude Sonnet 5.5 for the fresh-eyes lane).

   • Branch: fix/workflows-sandbox-send-guards, cut from the Sandbox sender: keep sends out of tier history and record the first sandbox delivery #236 head d9ef8d19c62
   • Ships together with Sandbox sender: skip sandbox sends when the sandbox route settings are empty #281 and Sandbox sender: claim daily cap tokens once when SES throttles a send #278 in one draft PR, one commit set per ticket (Sandbox sender: skip sandbox sends when the sandbox route settings are empty #281 first)
   • Cap: 4 hours, until 21:58 UTC
   • CodeRabbit: slot 1 of 3
5. Silthus commented on Oct 5, 2026

   

   Silthus

   on Oct 5, 2026

   OwnerAuthor

   More actions

   Done by impl-278-281. Ships together with #281.

   PR: #112071 (draft, cumulative, stacked on PostHog#111904). Clean head b6e1ba75e0f, review delta d9ef8d19c62..b6e1ba75e0f.

   • Behavior: a sandbox send that SES throttles returns its daily cap claim before it is rescheduled, so the retry spends the tokens once. The return is replay-safe: each grant has a claim ID with a marker, and a return that arrives after a short deadline is dropped. A failed return leaves the tokens spent, which only tightens the cap.
   • Proof: email.service.test.ts, a send throttled once then accepted spends one token per recipient copy, and the next send hits the project cap. rate-limiter.service.test.ts covers a doubled and a late return. Each failed before its fix. Local gate green; fork CI waits for maintainer approval.
   • Calls: returned the claim instead of carrying it with the rescheduled send, which would need a trusted marker on the queued email parameters. Kept a failed return as spent instead of skipping the send, which would drop an email SES only throttled.
   • QA: two panel rounds (GPT-6.1 Sol and Claude Opus 5.5) plus the CodeRabbit bot. The replay findings were fixed; the rest are in the PR's agent context.
   • New settings: none.
   • Follow-up candidate: own-domain SES throttle retries do not restore the email queue parameters (raised by CodeRabbit; the path is the same on master).
6. Silthus

   closed this as completedon Oct 5, 2026