Opt-out honored during queue backlog

GDPR Article 7(3) and CAN-SPAM §7704(a)(4) impose time-bounded opt-out obligations with no exception for queue backlog. When a large campaign send floods the job queue at the same time as incoming opt-out requests, a FIFO queue without priority differentiation can delay opt-out processing by hours — pushing real contacts into violation territory. Separately, if the campaign recipient list is built at scheduling time (hours before send), contacts who opted out after list construction will be in the send batch regardless of the queue's behavior. Both failure modes cause sends to contacts who have legally withdrawn consent.

Set explicit job priority in BullMQ (lower number = higher priority) and rebuild the recipient list immediately before send, not at schedule time:

// src/workers/queue.ts — opt-out jobs at priority 1, campaign sends at priority 10
await queue.add('process-optout', data, { priority: 1 })
await queue.add('send-campaign-email', data, { priority: 10 })

// src/lib/campaigns/recipients.ts — called at send time, not schedule time
async function getCampaignRecipients(campaignId: string): Promise<string[]> {
  const baseList = await db.campaignAudience.findMany({ where: { campaignId } })
  const ids = baseList.map(r => r.contactId)
  const suppressed = await db.contact.findMany({
    where: { id: { in: ids }, optOutStatus: { not: null } }
  })
  const suppressedSet = new Set(suppressed.map(c => c.id))
  return ids.filter(id => !suppressedSet.has(id))
}

Never cache the recipient list for more than 5 minutes before the actual send batch starts.