Fail-safe blocks sends to pending-unsubscribe contacts

GDPR Article 7(3) and CCPA §1798.120 require opt-outs to be honored — a race condition between async opt-out processing and a campaign send batch is not an acceptable excuse for sending to a contact who withdrew consent. CWE-284 (Improper Access Control) captures the broader class: the system fails to enforce the access control decision (do not send) during the window between request and processing. A contact who unsubscribes at 11:58 PM and a campaign batch that starts at midnight will be sent a campaign if the only guard is the processed consent record, which the async worker has not yet written.

Write the optOutStatus: 'pending' flag synchronously before enqueuing the job, so the pre-send guard can catch pending opt-outs even before the worker runs:

// src/app/api/unsubscribe/route.ts
export async function POST(req: Request) {
  const { contactId, scope } = await req.json()

  // Synchronous — takes effect immediately on all subsequent pre-send checks
  await db.contact.update({
    where: { id: contactId },
    data: { optOutStatus: 'pending', optOutRequestedAt: new Date() }
  })

  await queue.add('process-optout', { contactId, scope })
  return new Response(null, { status: 202 })
}

// Pre-send guard in src/lib/campaigns/can-send.ts
async function canSendCampaign(contactId: string, scope: string): Promise<boolean> {
  const contact = await db.contact.findUnique({ where: { id: contactId } })
  if (contact?.optOutStatus === 'pending' || contact?.optOutStatus === 'completed') return false
  return hasConsent(contactId, scope)
}

The synchronous status write costs one extra database round-trip but eliminates the race window entirely.