Transacciones a medias y reversión

Una transacción de base de datos agrupa varios cambios para que se apliquen todos o ninguno. Si algo falla antes de confirmarla, la reversión devuelve las tablas a como estaban. En Laravel, DB::transaction() hace las dos cosas sola: si el bloque termina, confirma; si una excepción sale del bloque, revierte y la vuelve a lanzar. Con DB::beginTransaction() el control es manual, y entonces cada camino de salida tiene que terminar en commit o en rollBack.

Lo que la reversión no alcanza es todo lo que ocurrió fuera de la base de datos aunque se haya escrito dentro del bloque: una llamada HTTP a una pasarela, un correo enviado, un archivo escrito, un mensaje publicado en una cola. Esos efectos ya salieron y no hay motor que los deshaga. El Top 10 de OWASP lo resume como regla de diseño: si una transacción de varios pasos falla a mitad, se revierte entera y se empieza de nuevo, porque intentar rescatar un estado parcial suele producir errores peores.

Abre el laboratorio y lee ConfirmarPedido.php con registro-aplicacion.txt al lado. El orden de los pasos importa: algunas fallas ocurren antes del cobro y no dejan rastro fuera de la base; otras ocurren después, cuando la pasarela ya aprobó. Busca en el registro las confirmaciones que llegaron a tener un cobro aprobado y aun así terminaron en reversión.

El alcance de este hallazgo se mide en pesos. Cruza reporte-pasarela.txt con pedidos-exportados.txt: un cobro aprobado cuyo pedido quedó pendiente y sin número de cobro es dinero que el cliente pagó por nada. Ten en cuenta que soporte ya anuló uno de esos cobros a mano tras un reclamo; ese ya no hay que devolverlo.

El otro reclamo del día fueron pedidos rechazados por «tiempo de espera de bloqueo» en un producto con existencias. Lee ReservarDomicilio.php y registro-motor.txt. Este código corre en un trabajador de colas, un proceso de larga vida que mantiene la misma conexión a la base entre un trabajo y el siguiente. Una transacción abierta a mano que sale por un camino sin commit ni rollBack sigue viva en esa conexión, con sus bloqueos, hasta que el proceso muere. El registro del motor muestra la sesión que quedó así y a quién hizo esperar.

La reserva tiene un arreglo directo: usar la forma con bloque, como ya hace liberarReserva, o revertir antes de cada salida. El cobro pide un rediseño, porque es el único paso que la base de datos no puede deshacer. Ese paso no debe quedar atrapado entre otros que pueden fallar después: el pedido se guarda primero como pendiente de pago, el cobro se hace con una llave única por pedido para que repetirlo no cobre dos veces, y lo que falle después, como la factura, deja el pedido pagado con un pendiente que se reintenta, no lo borra. Si alguna vez hay que deshacer un cobro, se hace con una anulación explícita que queda registrada.