Retries are idempotent — no duplicate sends

A worker that calls the ESP, receives a success response, and then crashes before updating the database leaves the job in an unacknowledged state. BullMQ re-queues it, and the next worker pickup sends an identical transactional email — a password reset, an order confirmation, a payment receipt — to a real recipient who has already received it. CWE-362 covers race conditions on shared resources; this is the classic check-then-act race across a network boundary. Unlike the queue-level dedup check, this pattern fails specifically on the retry after a successful-but-unacknowledged send.

Establish the 'sending' status in the database before calling the ESP, and check for it on every retry, in workers/email.worker.ts:

async function processEmailJob(job: Job<EmailJobData>) {
  const { campaignId, recipientId } = job.data
  const log = await db.emailSendLog.findFirst({
    where: { campaignId, recipientId }
  })
  if (log?.status === 'sent') return
  if (!log) {
    await db.emailSendLog.create({
      data: { campaignId, recipientId, status: 'sending', jobId: job.id }
    })
  }
  const idempotencyKey = `${campaignId}:${recipientId}:${job.id}`
  await esp.send({ ...job.data, idempotencyKey })
  await db.emailSendLog.update({
    where: { campaignId_recipientId: { campaignId, recipientId } },
    data: { status: 'sent', sentAt: new Date() }
  })
}