Never re-trigger an SES send (or any titan_email.send call) when a previous invocation is still in flight, even if boto3.Session() appears to be hanging.
Why: On 2026-05-03, the daily-briefing scheduled task's first SES send succeeded (MessageId 0100019dee34c191...) but produced no stdout for ~2 minutes. A separate watchdog probe of boto3.session.Session() timed out at 20s, triggering my assumption of a hang. I re-ran the script; the second send also succeeded (MessageId 0100019dee37d9d1...). Result: Harnoor received two identical briefing emails. Root cause was boto3's cold-start latency plus Windows credential-provider chain delays on this host.
How to apply: Before re-running titan_email.send or any script that calls it, verify the prior background job has actually exited (wait for Bash notification + exit code). If status is still running, wait — do not start a second sender. Only kill the original if a true hang must be diagnosed, and then proceed fresh.
---
Never call titan_email.send() with test payloads to diagnose hang/connectivity. SES has no dry-run mode — every send delivers a real email to the user's inbox.
Why: On 2026-05-03 daily-briefing run, I called titan_email.send(subject='TITAN Daily Briefing TEST · Sun May 3', body='ping', html='<p>ping</p>') as a "minimal probe to see if SES was alive." That probe successfully delivered a third email (MessageId 0100019dee3c5724-…) to Harnoor's inbox on top of the briefing + duplicate. SES does not distinguish between "real" and "test" sends — all calls to send_email() land in the recipient's inbox.
How to apply: For SES diagnostics use client.get_send_quota(), client.get_send_statistics(), or client.list_identities() — never client.send_email() and never titan_email.send(). If a sandboxed-send tool is needed, build it as a separate function that hits the boto3 client directly and short-circuits before send_email().