[clbotdev]

Summary

A sequence whose only email was set to 13 days showed "Sent 3" the day after it was activated. Enrollment set the first send to "now", and the first email's delay was never read: only follow-up emails waited their delay.

Fix (e1e09a1)

• When a trigger enrolls a contact in a sequence, the first published email is scheduled at entry time plus its delay. Broadcasts are unchanged, because their first delay is their send time.
• New sequences start with a first-email delay of 0, so existing setups behave as before. A sequence whose first email has a delay (edited, or reordered so a 1-day email is first) now waits that long.
• Docs and the MCP delayInMillis description say where delays count from.

Guardrails (d5948e5)

• Multi-day journey test: enroll, poll and send under a faked clock (setSystemTime). It fails if the fix is reverted.
• Report-only early-send check: after a sequence's first email is sent, check that its delay had passed since the contact entered. If not, log a warning and send sequence_email_sent_early (sequence_id, email_id, ongoing_sequence_id, early_by_ms) to PostHog. Later emails aren't checked, because reordering or deleting emails legitimately changes their timing. Skipped when the email or the sequence changed after the contact entered, which also covers contacts enrolled before this fix.

Visibility (b45c23d)

• Sequence stats gain Waiting. Each email row shows "N waiting", so a delayed email reads as waiting, not sent.
• Clicking the count opens a dialog listing the waiting contacts with their own due times, soonest first, with search by email or name and paging. Each contact's delay counts from their own entry, so the list doesn't show one shared date.
• API: GET /sequences/:sequenceId/schedule and GET /sequences/:sequenceId/emails/:emailId/waiting (q, after, limit; a cursor that can't be read returns 400 invalid_cursor).
• MCP: get_sequence_schedule, list_sequence_email_waiting_contacts.
• SequenceEmailList gains renderEmailDetail.

Review fixes (4e9c782)

• The early-send check covers only the first email and runs after a successful send, so failed or retried sends and older enrollments don't raise false reports. Adding or deleting an email now updates the sequence's updated_at.
• Contact search matches %, _ and \ literally, on the contacts page too.
• Short delays read "30 minutes" or "2 hours", not "0.0 days".
• "N waiting" counts refresh after a reorder, publish, add or delete.
• Clicking Next right after opening the dialog no longer jumps back to page 1.
• The MCP output schemas come from the REST contract.

Migration

0030_waiting_contacts_index adds ongoing_sequences (sequence_id, next_email_scheduled_time, id). Without it, a sequence's list walks every other sequence's rows in the global due-time index.

100,005 waiting, 400,000 in another sequence	Before	After
First page, worst case	427 ms	0.4 ms
Last page	184 ms	0.2 ms

Drizzle runs migrations in a transaction, so the build blocks writes to ongoing_sequences while it runs: about 1 s for 500k rows, and instant at today's size. The migration uses IF NOT EXISTS (0e1d31b), so if the table ever gets large enough to matter, a future index like this can be built by hand with CONCURRENTLY first.

Testing

• bun test --parallel src (api): 959 of 960 pass. The one failure is the pacing test "(Scope new-account pacing to the risk: don't throttle a customer's own ESP by account age #122)", which times out under parallel load and does the same on main.
• bun run test (web): 111 pass.
• Typecheck, lint, test:conformance and check:drift pass.
• E2E smoke against a local stack with Mailpit:
  • A 2.5-minute first-email delay arrived at +165 s, and a 0-delay email at +54 s.
  • Browser check of the Waiting stat and the dialog with 5 contacts and then 100,005: due order, search, and next and previous paging.

Follow-up

• Add a PostHog alert on sequence_email_sent_early.