Reply auto-pauses sequence for that contact

Detecting a reply and not acting on it is worse than not detecting it at all — the system now has evidence that a human responded and chose to continue sending anyway. CWE-841 (Improper Enforcement of Behavioral Workflow) applies: the reply event is received but the workflow does not enforce the expected state transition (active → replied). Pending BullMQ or Sidekiq jobs scheduled before the reply are the specific failure vector: updating the enrollment status in the database does not cancel jobs already enqueued. The contact receives the next step at the scheduled time despite the status update, because the job handler may not re-check enrollment status before sending.

In your handleReply function, update enrollment status and cancel pending jobs atomically — both actions must happen, not just the status write.

async function handleReply({ contactId, body }: ReplyEvent) {
  // Update all active enrollments for this contact
  await db.contactSequence.updateMany({
    where: { contactId, status: { in: ['active', 'paused'] } },
    data: { status: 'replied', repliedAt: new Date() }
  })

  // Cancel queued jobs — status update alone is not enough
  const pendingJobs = await queue.getDelayed()
  for (const job of pendingJobs) {
    if (job.data.contactId === contactId) await job.remove()
  }

  // Notify the assigned rep
  await notifyRepOfReply(contactId, body)
}

Also add a guard at the top of your send job handler: re-fetch enrollment status and return early if it is not 'active' — this covers the race window between status update and job execution.