fix(email): dry-run send no longer strands approved pipeline jobs

[oratis]

Summary

The last outstanding item from the 2026-08 review's follow-up list (the chip filed while writing #12's tests).

With no mail provider configured, the email.send worker took a dev fallback that returned early — before the pipeline_jobs sync, the thread row and the event. The contact reached status='sent' while pipeline_jobs.stage stayed at 'send' forever: the Pipeline page showed the job stuck mid-flight, "Sent / Monitoring" never incremented, and the thread view was empty.

That's every provider-less deployment — which is what CI is, and what a fresh self-host is before Resend is wired up.

The branch now skips only the provider call. Everything downstream runs with a synthetic { success: true, messageId: null, provider: 'dry-run' }, so the flow completes exactly as it would with a provider, minus the send: stage advances to 'monitor', the outbound email_replies row exists, and the 'sent' event carries dryRun: true so nobody mistakes it for a real delivery. Provider ids stay NULL because nothing was sent.

Tests that pinned the old behavior

Both the integration test and the Playwright spec asserted the bug as a deliberate canary — the spec's header said in as many words that it should be updated if the dry-run branch ever learned to sync the pipeline row. It has; both now assert the corrected flow.

The stage-gate assertion also stopped hardcoding "send" in the rejection message: the worker races it ('send' while queued, 'monitor' once the handler finishes), so which stage the second approve reports is timing, not behavior.

Verified in a browser against a provider-less server

Approving moved Awaiting Review 1 → 0 and Sent / Monitoring 0 → 1, the stage track advanced to its final node, and the row reads "Sent". DB after:

pipeline_job: {"stage":"monitor","email_sent_at":"2026-08-09 15:03:33","smtp_message_id":null}
contact     : {"status":"sent","sent_at":"2026-08-09 15:03:33","provider_message_id":null}
thread rows : 1 | events: [{"event_type":"sent","payload":{"provider":"dry-run","dryRun":true,...}}]

Test plan

• npm test 656/656
• Playwright 5/5 (both approve specs updated)
• Browser verification above

🤖 Generated with Claude Code

[oratis]

Review: approving — fix is correct and complete, one gap closed on top

Traced the whole email.send handler rather than the diff in isolation, because the change's safety rests on what the shared success path does after the branch. It holds up: everything the old dry-run UPDATE did is preserved downstream —

old dry-run UPDATE	where it happens now
status='sent', sent_at	success path, non-follow-up branch
send_error=NULL	same statement
send_attempts+1, last_send_attempt_at	the pre-send increment

So no field regresses, and stage='monitor' + thread row + event are net-new. The atomic claim from #10 is upstream of the branch and untouched, so dry-run still can't double-send — confirmed by the existing double-approve test still passing.

Verified locally (not just trusting CI): merges clean onto main at 7df4183, and 678/678 server tests pass with --test-concurrency=1.

⚠️ On CI runs of this branch you may see 2–5 red files with { code: 'SQLITE_BUSY' }. That is not this PR: npm test runs files concurrently against the single shared influencex.db at the repo root, and it reproduces on main with no changes applied. Serialized re-run is green. I've documented this in #26 so it stops being re-diagnosed every time.

One real gap — fixed in 0a71092

The fix removes the only signal that a deployment has no mail provider. Jobs used to strand at stage='send', which at least looked broken; now the flow reports complete success and the dry-run branch logs nothing at all.

That reaches production, because nothing fails fast on a missing provider — server/email.js:29 isConfigured() is a plain boolean and no boot guard consults it:

return gmailEnv || !!process.env.RESEND_API_KEY || !!(process.env.SMTP_HOST && ...);

A revision that lost RESEND_API_KEY would report every outreach as delivered, with provider: 'dry-run' buried in the email_events payload as the only tell. I added a log.warn naming the three things it looked for and the contact it's about to mark sent without sending. No behavior change.

Minor, not blocking

The dry-run email_replies row is indistinguishable from a real outbound one except resend_email_id IS NULL — the dryRun label lives on the event, not the thread row. Fine for the stated goal (a non-blank UI), worth knowing if anything ever audits threads for real delivery.

Merging.