movilba
MOVILBA-255
Los 107 pares abierta+cerrada del mismo periodo: retirar la fila abierta obsoleta que el import inserto en vez de cerrar
Done high
dmdb02-mba-l-cc
db02, 2026-09-05, DEV. coder02 corrio rutap-sync-prod.sql con apply=true contra DEV: ya pasa el punto de 248/254 y ahora aborta mas abajo en 'gate: 22 current-state rows have multiple active historial matches; no id-order tie-break is applied' (tools/rutap-sync-prod.sql:~660). Nadie lo habia mirado. Es de esta familia, no de 248. EL 22 ES EL DENOMINADOR ANGOSTO DEL GATE. Sobre la tabla entera la condicion es MUCHO mas grande: 213 grupos (vehiculo_id, fecha_alta) con mas de una fila ACTIVA (borrado_en IS NULL), 428 filas, de 2 a 3 filas por grupo. El gate solo ve los que caen en su poblacion de estado actual. TRES CLASES, medidas, no supuestas: - 108 grupos con el patron limpio: una fila VIEJA abierta (fecha_baja NULL) y una NUEVA cerrada, MISMO expte_alta. O sea el import nuevo INSERTO la fila de cierre en vez de cerrar la abierta. La vieja quedo como periodo abierto fantasma. Ejemplo AA013AA: id 4921 alta 2026-06-29 sin fecha_baja, id 16096 misma alta con fecha_baja 2026-09-01 y expte_baja 'Cesion a Nuevos Rumbos', mismo expte_alta EX-2026-30084951. - 86 grupos con MAS DE UNA FILA ABIERTA - la forma de MOVILBA-203, mas dificil: no hay una 'vieja' obvia para cerrar. - 12 grupos escritos en UN SOLO lote, o sea no es solo colision entre corridas. DOS LOTES DOMINAN, y la firma es el creado_en de microsegundo identico: 2026-06-22 10:50:32.25576 (184 filas / 184 vehiculos) y 2026-09-04 14:00:39.011938 (194 / 194). Los demas creado_en del grupo son fechas a medianoche, o sea fechas de NEGOCIO y no marcas de lote - creado_en NO es marca de lote para toda la tabla, solo para las filas con precision de microsegundo. POR QUE IMPORTA MAS QUE EL GATE: dos filas activas con la misma fecha_alta significan dos periodos abiertos para el mismo vehiculo, y la ficha resuelve 'el periodo vigente' entre ellas sin desempate declarado. El gate del sync tiene razon en plantarse: cualquier tie-break por id seria elegir un ganador en silencio (misma objecion que MOVILBA-89). NO CUBIERTO: PROD - todo esto es DEV. Y no mire si la ficha muestra una, otra o las dos. Emparenta con MOVILBA-171 (9 filas OCULTAS con periodo abierto, poblacion distinta: aquellas tienen borrado_en NO NULL) y con MOVILBA-203.
Sub-tickets — 1/1 done
MOVILBA-260 Done high
dmdb03-mba-l-cc
Activity
-
db02, alcance del arreglo, tomado de audit-mba-l-cc y NO negociable al implementar: (1) el creado_en de microsegundo identico identifica un LOTE, no un ESCRITOR - prueba que esas filas se escribieron en una sentencia, no quien la corrio ni con que intencion. La evidencia que sostiene el hallazgo es el split 108/86/12; las dos marcas de lote son corroboracion. (2) Los 86 grupos con MAS DE UNA FILA ABIERTA son un defecto DISTINTO de los 108 con periodo abierto fantasma, y solo el segundo tiene reparacion obvia (cerrar la vieja con los datos de la nueva). Un arreglo disenado sobre los 108 y aplicado a los 213 INVENTA un desempate, que es exactamente lo que el gate se niega a hacer. Se arreglan por clase, con su propio gate cada una, o no se arregla.
-
db02 2026-09-05, ANTES DE ESCRIBIR EL ARCHIVO DE REPARACION: medida la poblacion en detalle, la premisa del arreglo es FALSA para 66 de los 108. Las dos filas del par NO coinciden en el contenido del periodo: entidad_id difiere en 54 grupos, linea_id en 10, observaciones en 12; al menos una de las tres difiere en 66. Cerrar la fila vieja con la fecha_baja de la nueva dejaria dos filas del mismo periodo contradiciendose sobre que entidad o que linea tuvo el vehiculo, y con cara de reparado. DOS DIFERENCIAS NO SON CONFLICTO Y NO SE CUENTAN: tramite difiere en 108/108 pero la fila VIEJA lo tiene NULL en 107 - es ausencia, no desacuerdo, el lote de junio no lo poblaba. Y estado_id difiere en 98, con la fila NUEVA en NULL en 95 - es la regla documentada del loader (nunca escribe estado_id ni motivo_id en vehiculo_historial). Sacando esas dos: 66 CON conflicto de contenido, 42 SIN. LA FORMA DEL PAR: vieja del lote 2026-06-22 10:50:32.25576, abierta, tramite NULL, estado poblado, entidad de junio. Nueva del lote 2026-09-04 14:00:39.011938, cerrada, tramite Modif o Alta, estado NULL, entidad actualizada. AA013AA: entidad 71 en la abierta y 54 en la cerrada, y el expediente de cierre es 'Cesion a Nuevos Rumbos'. El import nuevo no re-cerro un periodo existente: escribio el periodo otra vez con OTRA entidad y dejo el viejo abierto. CONSECUENCIA DE ALCANCE: la clase mecanicamente reparable son 42 grupos, no 108. Los 66 necesitan decidir cual entidad/linea/observaciones es la verdad del periodo, y eso lo contesta el LIBRO, no nosotros. Esperando decision de coder02: archivo para los 42 y los 66 como item aparte, o esperar y hacer un solo archivo cuando los 66 esten clasificados.
-
db02 2026-09-05, el LIBRO resuelve los 66 y el alcance cambia otra vez: 107 mecanicos + 1 a mano, no 42 + 66. Todo SELECT. (a) Los 66 grupos con conflicto tienen EXACTAMENTE UNA fila en el libro (snapshot 10). Ninguno es ambiguo, ninguno falta. No hay pregunta para Eugenia aca. (b) El libro coincide con la fila NUEVA (la cerrada) en todos menos uno: entidad 54/54 - la empresa del libro resuelve a la entidad de la fila cerrada, cero sin resolver -, linea 10/10, observaciones 11/12. La regla de reparacion es uniforme y verificada contra el libro campo por campo: LA FILA CERRADA MAS NUEVA ES EL PERIODO, LA ABIERTA VIEJA ES BASURA. (c) La excepcion es AG986KG, fecha_alta 2026-04-15, y se da vuelta dos veces. El libro trae la observacion larga ('Se dió de baja por error el 21/04 con EX-2026-18235670...') que esta en la fila ABIERTA (id 10817, escrita 2026-08-28); la CERRADA (id 10058, 2026-08-21) trae la frase generica. O sea aca el libro le da la razon a la abierta, y la abierta es ademas la MAS NUEVA: 107 de 108 pares tienen la cerrada mas nueva por creado_en, este es el unico al reves. Mismo vehiculo que MOVILBA-157, misma forma que MOVILBA-236. MOVILBA-248 no toco ninguna de las dos filas (ninguna esta en respaldo.m248_legacy): la frase la puso el import. (d) PENDIENTE DE DECISION DE MODELO, no la tomo solo: como deja de estar abierta la fila vieja. DELETE se rechaza y el trigger lo convertiria igual. Escribir borrado_en la retira, pero en vehiculo_historial borrado_en es la MARCA DE PERIODO CERRADO (MOVILBA-83), y usarla para retirar un duplicado la sobrecarga por tercera vez. Copiar la fecha_baja de la cerrada deja dos filas cerradas del mismo periodo y el gate del sync sigue disparando. La tercera opcion es no tocar el dato y arreglar el lector.
-
ARTEFACTO LISTO Y ENSAYADO, NO APLICADO. docs/migrations/2026-09-05-movilba-255-retirar-filas-abiertas-duplicadas-DEV.sql, md5 cbe5370323abf9308a2c9e79e9e57e96, 309 lineas. Espera GO. POBLACION, re-derivada hoy en DEV: 108 pares (vehiculo_id, fecha_alta) con exactamente 2 filas activas, exactamente 1 abierta y 1 solo expte_alta distinto. 107 se reparan, 1 queda excluido. La exclusion se DERIVA de la propiedad ('la abierta es mas nueva que la cerrada'), no del dominio: gatear por AG986KG seria gatear por el sintoma. EVIDENCIA DE LA REGLA, medida y no asumida: de los 108, 66 tienen contenido en conflicto; LOS 66 resuelven a EXACTAMENTE UNA fila del libro y el libro coincide con la fila CERRADA (entidad 54/54, linea 10/10, observaciones 11/12). El unico par donde el libro le da la razon a la ABIERTA es el excluido, y es tambien el unico donde la abierta es la mas nueva. Ninguno de los 66 es pregunta para Eugenia. QUE ESCRIBE: solo public.vehiculo_historial.borrado_en, solo en las 107 abiertas que nombra respaldo.m255_pares. borrado_por queda NULL a proposito. No toca ninguna fila cerrada, ni los 86 grupos con mas de una abierta, ni la tabla ancha, ni el espejo raw, ni PROD. ENSAYO, COMMIT->ROLLBACK, 14 corridas: 1 limpia EXIT=0 y 13 siembras que abortan EXIT=3 cada una con SU PROPIO mensaje. Cubre 4 guardas de entrada (denominador cero; ningun par excluido; fecha_alta del libro fuera de ISO; el libro deja de resolver) y G1..G9 (abierta que sigue activa / cerrada retirada / par excluido tocado / borrado_por escrito / se retiro una fila ajena / el par reparado no quedo con una sola activa / cambio el contenido de las cerradas por firma md5 tomada en el pre-estado / se invento una fecha_baja / el respaldo nombra una fila que ya no esta en la tabla viva). DEV verificado intacto despues: 501/52/5577 igual que antes, respaldo.m255_pares no existe, y la poblacion re-derivada vuelve a dar 108/1/66/0. DOS DEFECTOS PROPIOS QUE EL ENSAYO ENCONTRO Y ESTAN CORREGIDOS EN EL ARCHIVO: (a) un alias de tabla llamado 'p' adentro de un DO block resuelve contra la variable record 'p' y abortaba con 'record p has no field'; (b) el gate del libro casteaba a date una columna de TEXTO sin asegurar la forma ISO. Los dos habrian abortado el archivo entero al ejecutar. LO NO EJERCITADO: no se ejercito ninguna corrida sobre PROD, ni el par excluido reparado por otra via, ni los 86 grupos multi-abierta, ni el efecto sobre v_vehiculos_export (ese camino resuelve observaciones/expedientes contra vehiculos_datos_colectivos, no contra vehiculo_historial). Y esto NO desbloquea tools/rutap-sync-prod.sql: sus 22 son un subconjunto de los 213 y el gate sigue abortando con un numero mas chico.
-
db02: artefacto escrito y ensayado (md5 cbe5370323abf9308a2c9e79e9e57e96, 14 corridas, 13 siembras que disparan, DEV verificado intacto). Esperando el GO de Elazar, relayado por coder02. No aplicado.
-
db02 2026-09-05: LA EVIDENCIA DEL ARCHIVO RE-MEDIDA CONTRA EL LIBRO NUEVO, ANTES DE QUE CAIGA EL GO. Elazar bajo /data-lezama/rutap-ssot/2026-09-05-0649-parque-rutap.xlsx (md5 f0bbfda7f5b70e6509b29ff9dc144f8f) a las 06:49 y NO esta importado; DEV sigue en snapshot 10. Toda la evidencia de este item se habia medido contra el snapshot 10, o sea contra el libro anterior (09-04 11:54). Un GO que llegue ahora se apoyaria en una premisa medida contra otro libro, asi que se volvio a correr la misma pregunta leyendo el xlsx nuevo directo, sin importar nada. LIBRO NUEVO: 5388 filas de datos, 2407 dominios (snapshot 10: 5370 / 2406). RESULTADO, y la premisa SOBREVIVE: - Los 108 pares resuelven a EXACTAMENTE UNA fila del libro nuevo. Distribucion sobre los 108: {1 fila: 108}. Ninguno con cero, ninguno con dos. - Los 66 pares en conflicto: 66 de 66 resuelven a una sola fila. - Y el contenido tambien, que es lo que la cardinalidad no ve: comparando Observaciones del libro NUEVO contra la fila CERRADA de cada par en conflicto, 65 de 66 COINCIDEN exactamente. El unico que difiere es AG986KG, que es la exclusion deliberada del archivo: el libro nuevo le sigue dando la razon a la fila ABIERTA ('Se dio de baja por error el 21/04 con EX-2026-18235670-...') contra la generica de la cerrada. O sea que un libro POSTERIOR e INDEPENDIENTE vuelve a producir la misma particion: 107 donde el libro respalda a la fila cerrada y 1 donde no, y es el mismo. La regla del archivo y su unica exclusion quedan confirmadas contra dos libros distintos, no contra uno. NO EJERCITADO: solo se comparo la columna Observaciones. Entidad y linea NO se re-midieron contra el libro nuevo porque exigen resolver empresa->entidad_id y linea->linea_id fuera de la base, y el libro nuevo no esta importado. Tampoco se midio el delta del libro nuevo contra el snapshot 10 (+18 filas, +1 dominio) - eso es MOVILBA-265 y es de db03. El archivo de la migracion no cambio: sigue en md5 cbe5370323abf9308a2c9e79e9e57e96.
-
db02 2026-09-05 07:41 ART: APLICADO EN DEV, COMMIT, EXIT=0. Archivo docs/migrations/2026-09-05-movilba-255-retirar-filas-abiertas-duplicadas-DEV.sql, md5 cbe5370323abf9308a2c9e79e9e57e96 verificado inmediatamente antes de correr - los bytes que el GO nombra, sin editar. GO de coder02-mba-l-cc, que es el PM del ARO mba-l (verificado contra aros_pm, no contra memoria). QUE ESCRIBIO: UPDATE 107 sobre public.vehiculo_historial.borrado_en = now(), las filas nombradas por respaldo.m255_pares. Nada mas. Sin DELETE, sin DISABLE TRIGGER, borrado_por sin tocar. MEDICIONES, denominadores re-derivados en la corrida: - pre: 108 pares, 107 a reparar, 1 excluido por propiedad, 66 con conflicto de contenido, 501 filas ya con borrado_en, 52 con borrado_por, 5577 activas. - post: 608 con borrado_en (predicho 608), 52 con borrado_por, 5470 activas, 6078 total. El total no se movio: no se creo ni se borro ninguna fila. - Los 66 pares en conflicto resuelven a EXACTAMENTE UNA fila del libro en el snapshot 11 del lado RAW (rutap.v_rutap_latest, 5388 filas / 2407 dominios). 0 no resuelven. - Respaldo: /data-lezama/import-reports/2026-09-05-movilba-255-pares-pre-estado.tsv, 108 filas, 13781 bytes. Barrido por valores con forma de CUIT: 0. LA MARCA DE RETIRO ES now() EN UNA COLUMNA QUE TAMBIEN GUARDA UNA FECHA DEL LIBRO. MOVILBA-83 midio que borrado_en en vehiculo_historial guarda la Fecha Baja del libro, no una eliminacion. Estas 107 filas quedan con 05/09/2026, una fecha que el libro NUNCA dice para ellas. Es tolerable SOLO mientras nada de cara al usuario lea esta tabla - desde el cutover de MOVILBA-204 la ficha lee la tabla ancha via getRutapHistorialByChain (medido por coder02 el 09-05, MOVILBA-170), y el lector que queda es v_vehiculo_historial via getFechaAltaMasReciente, cuyo defecto propio es MOVILBA-225. ANTES DE QUE ESTA TABLA VUELVA A SER DE CARA AL USUARIO, MOVILBA-83 TIENE QUE RESOLVER LA SOBRECARGA. Un lector futuro NO debe encontrar 107 filas cerradas el 05/09/2026 y tomarlo por un dato del libro. La pertenencia se lee de respaldo.m255_pares y de ningun otro lado: la "firma" borrado_en NOT NULL + fecha_baja NULL no las distingue, ya habia 101 filas asi antes. RESIDUAL, MEDIDO, Y NO ES UNA FALLA: grupos (vehiculo_id, fecha_alta) con dos filas activas hoy = 104. Clasificados: 86 tienen las DOS filas abiertas, 14 las dos cerradas, 3 tienen una abierta pero dos expte_alta distintos, y 1 es la exclusion deliberada AG986KG. Ninguna es la forma de 255, que pedia exactamente una abierta, una cerrada y un solo expte. De esa forma no queda ninguna salvo el par excluido. Las 86/14/3 son MOVILBA-260 y 271, no de este archivo. DOWN: UPDATE public.vehiculo_historial SET borrado_en=NULL FROM respaldo.m255_pares p WHERE id = p.id_abierta AND NOT p.excluida. NO DROPEAR respaldo.m255_pares hasta que 255 cierre - es el DOWN y la definicion de la poblacion. NO EJERCITADO: PROD sin tocar y fuera de alcance. No abri ninguna ficha para confirmar que la tabla ya no se renderiza; eso lo tomo de la medicion de coder02 en MOVILBA-170, no lo re-derive.
-
db02: aplicado en DEV con COMMIT, EXIT=0, 107 UPDATE, 608 con borrado_en como se predijo. Solo DEV; PROD fuera de alcance.
-
Los 107 pares abierta+cerrada del mismo periodo: retirar la fila abierta obsoleta que el import inserto en vez de cerrar
-
TITULO CORREGIDO 2026-09-05 07:44 por coder02. El titulo viejo decia '213 grupos' y ese nunca fue el alcance de ESTE archivo: 255 repara la forma exacta 'una abierta + una cerrada + un solo expte_alta', que son 108 pares, 107 reparados y 1 excluido por su propiedad (AG986KG). Aplicado en DEV el 07:41 por db02-mba-l-cc, EXIT=0, md5 cbe5370323abf9308a2c9e79e9e57e96. EL RESTO NO SE PERDIO, tiene dueño: quedan 104 grupos con dos filas activas para un mismo (vehiculo_id, fecha_alta) - 86 con las DOS abiertas, 14 con las dos cerradas, 3 con una abierta pero dos expte_alta distintos, y 1 es la exclusion deliberada. Los 86/14/3 son MOVILBA-260 y MOVILBA-271; ninguno es la forma de 255. MARCA DE RETIRO: borrado_en = now(). Es una columna SOBRECARGADA - guarda tambien la Fecha Baja del libro (MOVILBA-83) - asi que 107 filas quedan con fecha 05/09/2026 en una columna que en otro lado se lee como fin de periodo de negocio. Tolerable SOLO mientras ninguna superficie de usuario lea public.vehiculo_historial: desde el cutover de MOVILBA-204 la ficha lee la tabla ancha. Antes de que esa tabla vuelva a ser de cara al usuario hay que resolver la sobrecarga en MOVILBA-83. Un lector futuro NO debe tomar esas 107 fechas por un dato del libro. ROLLBACK vivo: UPDATE public.vehiculo_historial SET borrado_en=NULL FROM respaldo.m255_pares p WHERE id=p.id_abierta AND NOT p.excluida. No borrar respaldo.m255_pares.
-
db02 2026-09-05, EFECTO DE LA ESCRITURA MEDIDO DESPUES DEL COMMIT. Todo SELECT. 1. v_vehiculo_historial NO FILTRA vh.borrado_en. Leido con pg_get_viewdef: el unico predicado de borrado_en es JOIN vehiculos v ON vh.vehiculo_id=v.id AND v.borrado_en IS NULL, o sea sobre VEHICULOS, no sobre la tabla de historial. La vista incluso expone vh.borrado_en como columna. Las 107 filas nunca salieron de esta vista. 2. getFechaAltaMasReciente NO SE MUEVE, medido de los dos lados y no argumentado: sobre los 107 vehiculos afectados, max(fecha_expediente) con tramite ALTA (opcion 317) es IDENTICO con y sin las filas retiradas. Cambiaron 0. Cayeron al fallback de vdc 0. Ya estaban en el fallback 0. La razon: solo 6 de las 107 tienen tramite ALTA, 101 son MODIF, y la fila cerrada del par trae la misma fecha_alta. 3. CONSECUENCIA REAL, EN OTRA COLUMNA QUE LA QUE SE TEMIA: la vista calcula periodo_hasta = COALESCE(vh.fecha_baja, vh.borrado_en::date). Las 107 tienen fecha_baja NULL, asi que su periodo_hasta ahora es 2026-09-05. Medido: exactamente 107 filas de la vista tienen periodo_hasta = 2026-09-05 y las 107 son las que retiro 255; ninguna otra fila de la tabla muestra esa fecha. Cualquier consumidor que lea periodo_hasta dibuja esos periodos terminando HOY, una fecha que el libro no dice. Es la sobrecarga de MOVILBA-83 escrita adentro de una definicion de vista. 4. v_vehiculos_hist_ultimo SI filtra h.borrado_en IS NULL sobre la tabla de historial, asi que ahi las 107 quedan OCULTAS en vez de mal fechadas. No se midio si a algun vehiculo le cambio la fila ultimo. 5. VERIFICACION AL NIVEL DEL RENDER, hecha por proxy-mba-w-cc sobre tres fichas de DEV (POD394 id 5114, PQW567 id 5183, AA217GK id 3380): ninguna dibuja 05/09/2026 ni ninguna fecha de fin sin explicacion. La ficha lee el historial derivado del libro, no public.vehiculo_historial - confirma MOVILBA-204 al nivel del render y no por lectura de codigo. CONCLUSION: no se revierte. El numero que habria justificado revertir es 0. Lo que hay que arreglar es que periodo_hasta deje de coalescear borrado_en: esa columna confunde "el libro cerro el periodo" con "nosotros retiramos la fila". NO EJERCITADO: no se enumeraron los caminos de codigo que seleccionan periodo_hasta; no se midio el impacto en v_vehiculos_hist_ultimo; PROD sin tocar.
bug
5w ago by wi-cli-venus
5w ago
2026-09-05 10:42