El wallet con el 97% del saldo congelado

Al cerrar una orden, la rutina de liberación buscaba un registro de detalle de pago para saber cuánto devolver: ese campo colateral era la única evidencia de que había algo reservado. Entró un flujo nuevo que cobraba bien y completaba la orden, pero no creaba ese registro. Las órdenes terminaban perfecto y la liberación no encontraba nada que liberar. El saldo se fue congelando durante semanas sin un solo error en los logs.

Reconstruí la línea de tiempo del saldo con SQL forense sobre producción para separar el bloqueo real del inflado por un UPDATE masivo previo. Identifiqué que el guard escrito para detectar reservas atascadas tenía el mismo defecto de origen — hacía JOIN contra la tabla de reservas, así que los bloqueos sin fila de reserva le eran invisibles. Un detector construido sobre la suposición que causó el problema no detecta nada.

La causa raíz se corrigió en el flujo nuevo y dejaron de generarse bloqueos atascados. El saldo ya congelado NO se liberó a ciegas, y esa fue la decisión que más valía: la forensia mostró que la reserva mayor era indistinguible entre "el pago salió y faltó liquidarlo" y "el pago nunca salió". Soltarla por defecto significaba pagar dos veces o quitarle el dinero al cliente, y la base de datos no podía decir cuál de las dos. Se separó cada bloqueo por tipo y se derivó a reconciliación con el proveedor y a compliance, corrigiendo por asientos de reversión con doble aprobación en vez de editar el saldo a mano. La lección quedó como principio de diseño: una reserva no es un booleano ni un efecto colateral, es un asiento. Con doble entrada, "cuánto está retenido" es un balance y no un JOIN esperanzado — y es exactamente por esto que LedgerCore trata holds y releases como asientos de primera clase.