Suppression honored during queue processing

Email dispatch pipelines with a queue layer (BullMQ, SQS, Celery) introduce a window between job creation and job execution. A contact who unsubscribes or receives a hard-bounce notification after a campaign job is enqueued but before the worker processes it will still receive the email if suppression is only checked at scheduling time. Under CAN-SPAM § 5, a suppression request must be honored within 10 business days — a queue delay of minutes to hours is acceptable, but a suppression check that is only performed at enqueue time can miss suppressions that arrive during that window. GDPR Art. 21 right to object has the same gap risk: an objection processed into the suppression table after the job was queued still results in a send if the worker does not re-check.

Add a suppression check inside the worker function, immediately before the ESP send call — not only at job creation:

worker.process('send-email', async (job) => {
  const { to, templateId, data } = job.data

  // Re-check suppression at dispatch time — catches suppressions added after job was queued:
  if (await isSuppressed(to)) {
    await db.sendLog.create({
      data: { to, templateId, outcome: 'suppressed_at_send', job_id: job.id }
    })
    return  // Complete the job without sending
  }

  await esp.send({ to, templateId, data })
  await db.sendLog.create({ data: { to, templateId, outcome: 'sent', job_id: job.id } })
})

The first suppression check at enqueue time is still useful to reduce queue depth — keep both checks. The worker-level check is the safety net for the scheduling-to-dispatch window. Ensure isSuppressed queries the same global suppression table (see ab-000872), not a per-campaign exclusion list.