PON576 quedo sin ninguna fila viva de historial: el paquete de MOVILBA-104 le puso borrado_en a su ULTIMA fila
Auto-reportado por db02-mba-l-cc, que aplico el paquete. Medido en prod 2026-08-21 08:22 ART. PON576 es el UNICO vehiculo vivo de prod con cero filas vivas de vehiculo_historial: sus tres filas llevan borrado_en - id 7881 (2025-07-08 a 2025-12-09), id 7356 (2025-12-30 a 2026-07-02) e id 4905 (2026-07-02 a 2026-08-20), que es la que cerro el paquete 104 a las 07:29. LA CONVENCION QUE ROMPE, medida sobre los otros 137 vehiculos cerrados: 182 filas cerradas, 45 con borrado_en y 137 sin - exactamente una por vehiculo, la ULTIMA fila cerrada, que se deja con borrado_en NULL para que el vehiculo conserve una fila viva bajo uq_vehiculo_historial_activo. Los eslabones anteriores de la cadena SI reciben borrado_en porque el indice unico los obliga. QUE PASO: la WRITE 1 del paquete aplico el criterio de movilba-19 (fila cerrada lleva borrado_en = fecha_baja) a la fila FINAL de PON576. Para un insert multi-fila como las cadenas de AC343HD/AH007QZ ese criterio lo fuerza el indice; para la ultima fila que le queda a un vehiculo no lo fuerza nada, y aplicarlo convirtio a PON576 en la unica excepcion de un invariante que se cumplia en 1737 de 1738. POR QUE NO LO VIO NINGUN GATE, y es la parte que hay que aprender: todos los gates del paquete aseguraban conteos y la divergencia de estado, y ninguno aseguraba 'cada vehiculo vivo conserva una fila viva de historial'. Otra vez un chequeo que no puede dudar de su propia pregunta. ALCANCE, medido y no supuesto: v_vehiculo_historial NO filtra por h.borrado_en - devuelve las 4052 filas - asi que PON576 sigue apareciendo ahi y en v_vehiculos_hist_ultimo, que devuelve 1738. El dano esta confinado a los consumidores que eligen la fila viva con borrado_en IS NULL: para PON576 no encuentran nada. NO afecta a la opcion D de MOVILBA-109, que sirve a PON576 por la rama ALTA igual que a los otros 137. ARREGLO PROPUESTO, sin tocar hasta tener GO: un UPDATE que ponga borrado_en = NULL en vehiculo_historial id 4905, devolviendo el invariante a 1738 de 1738. No viola uq_vehiculo_historial_activo porque PON576 pasa de cero filas vivas a una. fecha_baja se queda en 2026-08-20, o sea que el cierre que el 104 estaba autorizado a hacer se conserva; esto solo saca un sello de soft-delete que la fila nunca debio llevar. Necesita su propio GO descrito - el GO del 104 no lo cubre - y sigue vigente el gate duro: es un UPDATE, jamas un DELETE ni un DISABLE TRIGGER sobre vehiculo_historial. NO bundlear con D.
Activity
-
PAQUETE LISTO Y ENSAYADO, esperando solo el GO de Elazar. db02-mba-l-cc ownea el loop (shipeo el defecto). docs/migrations/2026-08-21-movilba-pon576-borrado-en-PROD.sql, md5 6b08fc6bdd36278950b3ef859148197c, ensayado con apply=false y ROLLBACK forzado 08:24, 0.079s, gates en verde. Trae el gate del invariante ESCRITO ANTES de que audit lo pidiera: GATE PRE afirma 1737 de 1738 vehiculos vivos con exactamente una fila viva - o sea que el defecto esta presente y es el unico - y GATE POST afirma 1738 de 1738 Y ademas que cero vehiculos tienen mas de una, asi que falla en las dos direcciones y no solo en la que se espera. La escritura tambien re-afirma que fecha_baja 2026-08-20, expte_baja y tramite_id 318 sobreviven al UPDATE: el cierre que autorizo el GO del 104 queda PROBADO intacto, no supuesto. Una fila, una columna, ninguna secuencia tocada. Rollback de una sola sentencia, documentado en el encabezado.
-
REVISION LINEA POR LINEA de db-mba-l-cc, md5 6b08fc6b verificado en disco, 179 lineas: SQL FIRMADO. Re-midio cada predicado de gate contra prod viva 08:26 en vez de leerlos - GATE 0 devuelve 1, la re-afirmacion de cierre del WRITE devuelve 1 con expte_baja exactamente 'EX-2026-37422952- -GCABA-DGGSM', y la aritmetica del GATE PRE se cumple en vivo (1738 vivos, 1737 con exactamente una), o sea que PON576 queda fijado como la UNICA instancia y el paquete aborta si aparece una segunda. UN HALLAZGO, y NO esta en el camino ejecutable: la linea 31 del encabezado documenta el rollback como SET borrado_en = '2026-08-20'::timestamp, pero la columna es timestamp WITH TIME ZONE (valor actual 2026-08-20 00:00:00-03). Un literal sin zona asignado a timestamptz se resuelve contra el TimeZone de LA SESION que corra el rollback: desde una sesion en UTC guarda 2026-08-20 00:00:00+00, que es 2026-08-19 21:00:00-03, otro instante. El rollback solo es correcto si quien lo corre tiene la zona argentina puesta. Arreglo: el literal completo, '2026-08-20 00:00:00-03'::timestamptz. Es cambio de COMENTARIO, asi que va con diff filtrado que demuestre que esta confinado ahi - sin re-ensayo ni republicacion de md5, segun la regla acotada del 07:29. MISMA FORMA LATENTE AGUAS ARRIBA, sin accion: la WRITE 1a del paquete 104 escribio cf.fecha_baja::timestamp en esa misma columna timestamptz, o sea que el sello que ahora sacamos era el tambien dependiente de la zona de la sesion. Quedo bien porque el apply corrio en zona argentina. Guardado en memoria como reference_timestamp_literal_into_timestamptz_is_session_dependent y agregado al indice db; va a la plantilla del harness junto con el gate del invariante.
-
Confirmado en PROD por coder02 2026-08-21: PON576 tiene 0 filas de historial vivas y 3 en total. Ademas es el UNICO caso en prod - el conteo de vehiculos vivos sin ninguna fila viva de historial da exactamente 1. En DEV el mismo defecto da 131 (eso es MOVILBA-112, del import de faltantes), asi que son dos poblaciones distintas y no hay que mezclarlas.
-
APLICADO EN PROD por db02-mba-l-cc, 11:25, GO verbatim de Elazar ('111 112 109d go'). md5 1f91a7e3 verificado antes de las dos corridas. Ensayo verde, apply verde, mismos gates: GATE 0 (fila 4905 = PON576, cerrada 2026-08-20, sello presente, 0 filas vivas), GATE PRE (1738 vivos, 1737 con exactamente una fila viva - PON576 faltando, el defecto), WRITE (1 fila, solo borrado_en, cierre intacto), GATE POST (1738 de 1738). Verificado como svc_nextjs: fila 4905 borrado_en NULL, fecha_baja 2026-08-20 intacta, expte_baja intacto, tramite_id 318, borrado_por NULL (no deja autor huerfano, la forma de instalaciones no se reproduce). v_vehiculos_lineas_entidades: 1738 filas, 0 con dominio NULL - la fila en blanco de PON576 desaparecio, que era el sintoma visible. Contra-medido por db-mba-l-cc independiente: mismo resultado, invariante 1738/1738 en las dos direcciones. NOTA DE CARRERA: db03-mba-l-ca corrio un ensayo del mismo paquete un minuto despues sobre un handoff ya retirado; su GATE 0 fallo con '0 matches para borrado_en no-NULL' porque el defecto YA NO ESTABA. La precondicion del paquete rechazo al segundo ejecutor - por eso el cruce no produjo doble escritura. El gate funcionando, no un hallazgo.