Rescheduling is atomic

Non-atomic reschedules split a logically single operation into two sequential database calls: first release the old slot, then reserve the new one. If the new slot reservation fails (conflict, timeout, or error), the old slot has already been released — and the booking is now in an invalid state with no slot attached. CWE-362 (race condition) and CWE-841 both apply. The customer ends up with a booking record that points to no slot, or a booking that was moved to a slot that was simultaneously taken by another user. A transaction wrapping both mutations prevents this by rolling back the release if the reservation fails.

Wrap the availability recheck, old-slot release, and new-slot reservation in a single transaction in src/lib/booking-service.ts.

await db.$transaction(async (tx) => {
  const conflict = await tx.booking.findFirst({
    where: { slotId: newSlotId, status: { not: 'CANCELLED' } }
  });
  if (conflict) throw new ConflictError('New slot unavailable');

  await tx.booking.update({
    where: { id: bookingId },
    data: { slotId: newSlotId, startTime: newStartTime, status: 'CONFIRMED' }
  });
  // slot capacity adjustments go here too, inside the same transaction
});