On June 29 I checked issue #034 after it went live on my site. Its canonical page worked and the archive listed it, but the subscriber email had never gone out.
The site and the email read from the same issue entry, but they had separate completion paths. A push built and deployed the Next.js site. The email still required another production command. I checked the page and never ran that command.
I moved that second command into the deployment job. After the server finishes the site deploy, it runs node scripts/send-newsletter.mjs latest --if-unsent. The command resolves the newest public issue and checks durable send state before it contacts the email provider.
That state lives in a table called newsletter_issue_email_sends. The issue row starts as sending. It becomes sent only when every confirmed-recipient attempt succeeds, and a partial failure stays failed so the same issue can be retried. Each recipient also gets an idempotency key derived from the issue slug and a hash of the email address.
I sent issue #034 from production once, then deployed the new guard. The next deployment found the recorded row and returned alreadySent with zero attempted, zero sent, and zero failed. I checked those zero counts before closing the fix. The retry had not put the same message in the inbox twice.
Now I keep two receipts for every issue. The canonical page has to show the complete copy, while the newsletter landing page, archive, feed, and sitemap have to point at the right issue. The deploy log has to show attempted, sent, and failed counts. A second guarded check has to return alreadySent with no delivery activity. Until the web and email receipts exist, the issue stays open.