136 filas VIVAS de vehiculo_historial tienen estado_id NULL y v_vehiculos_lineas_entidades las publica: 136 de 1738 filas salen con estado nulo

Sub-tickets

Activity

• wi-cli-venus created · 2026-08-21
• wi-cli-venus commented · 2026-08-21
  SON 137 EN LA VISTA, NO 136 - Y LA DE MAS ES PON576, lo que hace VISIBLE el defecto de MOVILBA-111. Medido por db02-mba-l-cc en prod. vehiculo_historial.estado_id IS NULL: 2448 en total, 136 en filas VIVAS, 2312 soft-deleteadas. v_vehiculos_lineas_entidades: 1738 filas, 137 con estado_id NULL. La diferencia es una porque la vista tiene 1738 filas sobre 1738 vehiculos vivos mientras existen solo 1737 filas vivas de historial. La 137a no es una fila con estado NULL: es un vehiculo SIN NINGUNA fila viva de historial, asi que el join produce NULLs. Es PON576, vehiculo_id 5136 - y NO solo el estado: linea_id, numero_linea, color_linea, entidad_id, nombre_entidad, estado_id, expte_alta y asignado_en TODOS NULL. Un renglon completamente en blanco en una vista que lista vehiculos contra sus lineas y entidades. SON DOS DEFECTOS DISTINTOS QUE SE VEN IDENTICOS EN ESA VISTA, y hay que enunciarlos separados: 136 filas publican NULL porque la fila de historial realmente no tiene estado_id; 1 publica NULL porque el vehiculo no tiene fila viva que leer. Quien lee la vista no puede distinguirlos, y arreglar cualquiera de los dos deja el otro. Y ESTO ACOTA LOS 136: los 136 vehiculos afectados SI tienen una fila viva de vehiculos_datos_colectivos con estado_id - 136 de 136. O sea que el estado EXISTE para todos ellos; lo que falta es en la fila de historial. Eso convierte los 136 en un hueco backfilleable y no en informacion perdida, y abre la opcion de que la vista lea estado desde vdc. Ninguna de las dos se propone aca: es una decision y no hay GO.
• wi-cli-venus verified · 2026-08-21
  ORIGEN MEDIDO, 08-21 ~11:50 por db-mba-l-cc (prod + dev, SELECT). Deja de ser un misterio de decaimiento de datos: es UN DEFECTO DE LOADER CON AUTOR CONOCIDO, y por eso el arreglo es un backfill y no una investigacion. Los loaders NO SE SUPERPONEN EN ABSOLUTO - ni uno aparece en las dos listas: SIN estado (136): import-movilba-19 131 (todas CERRADAS, fecha_baja no nula), movilba-104-prod 2, import-rutap-2026-08-14-prod 2, import-movilba-24 1. CON estado (1601): system_import 1596, import-movilba-18 4, y el de forma de CUIT 20394678369 1. O sea que no son 136 filas que PERDIERON su estado: es un solo camino de importacion (import-movilba-19, 131 de las 136) que nunca escribio la columna, mas un punado de sueltas posteriores. Dev muestra la misma firma a mayor escala: 2532 de 2534 filas soft-deleted con estado NULL, dominadas por import-rutap-2026-08-13 con 2284. EL BACKFILL ES LEGITIMO Y LA FUENTE ES INEQUIVOCA. estado_id es columna de NEGOCIO, asi que la regla de columnas de auditoria de Elazar no la toca (contrastar con MOVILBA-118: borrado_por SI es de auditoria y ahi el hueco se queda). Las 136 de prod tienen fila viva en vehiculos_datos_colectivos con estado_id real, 136 de 136 (db02); las 131 de dev tambien, 131 de 131, y TODAS valen 117 / Baja - poblacion sin mezclar, sin juicio de valor, sin fuente faltante. INTERACCION CON MOVILBA-112, hay que escribirla o el proximo lector la lee como regresion: 112 revive 131 filas y las 131 tienen estado_id NULL (control positivo: las que llevarian estado son 0). Las filas vivas de dev con estado NULL pasan de 8 a 139 POR DISENO. 112 se aplica tal como esta firmado y NO se ensancha; 117 es el que cierra ese hueco. INTERACCION CON MOVILBA-115: la vista _alta conserva la condicion estado_actual_id IS NULL, asi que estas 136 filas mas PON576 siguen renderizando como Alta igual que antes. O sea que la poblacion de 117 hoy se muestra en la pantalla de Alta. DOS DEFECTOS DISTINTOS QUE SE VEN IGUAL EN LA MISMA VISTA (correccion de db02 sobre el 137 vs 136): el extra de la vista es PON576, que renderiza como fila COMPLETAMENTE EN BLANCO por falta de fila viva de historial contra la cual joinear - ese es MOVILBA-111, no este. Se presentan identicos y necesitan arreglos distintos.
• wi-cli-venus verified · 2026-08-21
  RETRACCION DE UNA LINEA DEL EVENTO ANTERIOR. El bloque "INTERACCION CON MOVILBA-115" que escribi hace minutos es FALSO y no debe usarse para secuenciar nada. Decia que la vista v_vehiculos_list_alta conserva "OR estado_actual_id IS NULL" y que por eso estas 136 filas mas PON576 siguen renderizando como Alta, y que la poblacion de ese disyunto se mueve segun el orden en que caigan 117 y 111. NO EXISTE ESA INTERACCION. Medido por db-mba-l-cc y re-verificado por db02-mba-l-cc, prod 12:11, SELECT: - v_vehiculos_list.estado_actual_id es vdc.estado_id, NO vehiculo_historial.estado_id. Son dos tablas distintas con el mismo nombre de columna. - vdc.estado_id esta declarada NOT NULL y tiene 0 nulos en las 2394 filas, incluidas las soft-deleted. El disyunto admite CERO filas hoy, no 137. - Chequeo independiente: _alta 1600 + _baja 138 = 1738 = la flota viva entera. No queda lugar para una fila admitida por el disyunto. Asi que este item (que backfillea vehiculo_historial.estado_id) y MOVILBA-111 no pueden mover ese disyunto en ningun orden. No hay acoplamiento, no hay secuencia 137 -> 1 -> 0 y no hay nada que coordinar entre los dos items. COMO SE COLO: era un numero REAL sobre el OBJETO EQUIVOCADO. 136/137 son de vehiculo_historial.estado_id, que si es la columna de este item; el disyunto lee la otra. El nombre de columna identico basto para que tres carriles lo dieran por bueno sin preguntar de que tabla venia. Es la forma de la clave demasiado angosta otra vez, esta vez con la TABLA como campo distintivo. LO QUE SI ES CIERTO Y VIVE EN EL ARCHIVO DE 115, NO ACA: el disyunto esta MUERTO POR RESTRICCION en el camino de la columna (vdc.estado_id NOT NULL) y DORMIDO POR DATOS en el camino del join (v_vehiculos_list hace LEFT JOIN a vdc, asi que un vehiculo vivo SIN fila de vdc seria admitido - hoy 1738 vivos contra 1738 filas vivas de vdc, sostenido por datos porque nada obliga esa correspondencia). Dos fuerzas distintas de "no puede pasar" en un mismo predicado y solo una esta garantizada. Es el segundo consumidor del hallazgo del 1:1 sostenido por datos en vdc y refuerza el caso de ponerle una restriccion a vdc.vehiculo_id. Todo lo demas del evento anterior (origen medido en import-movilba-19, backfill desde vdc legitimo por ser columna de negocio, e interaccion REAL con MOVILBA-112 que lleva las filas vivas con estado NULL de 8 a 139 en dev por diseno) se mantiene sin cambios.
• wi-cli-venus verified · 2026-08-21
  CORRECCION DE UNA FRASE DEL EVENTO ANTERIOR, y esta vez es una MISATRIBUCION, no un numero mal. Escribi que el hallazgo del 1:1 sostenido por datos en vdc "refuerza el caso de ponerle una restriccion a vdc.vehiculo_id". db-mba-l-cc NUNCA propuso esa restriccion - reporto una MEDICION (el 1:1 se sostiene por datos y no por construccion) y otro carril la convirtio en "la restriccion que propusiste", y yo la registre como consecuencia. Se retira. Nadie diseno eso. Y LA VERSION INGENUA SERIA ACTIVAMENTE ERRONEA, que es la parte que vale guardar. vehiculos_datos_colectivos ESTA CONSTRUIDA PARA VERSIONAR: tiene fecha_vigencia_desde / fecha_vigencia_hasta, y el indice ix_vdc_vehiculo_vigente es (vehiculo_id, id DESC) WHERE borrado_en IS NULL AND fecha_vigencia_hasta IS NULL - un indice parcial cuyo proposito entero es encontrar la version CORRIENTE entre varias, y que no tendria sentido si solo pudiera existir una fila por vehiculo. El esquema esta diciendo la intencion de diseno y es la contraria a un vehiculo_id unico. Medido en prod: 2394 filas de vdc, 361 cerradas (fecha_vigencia_hasta NOT NULL), 138 cerradas Y VIVAS, 1738 vivas, 1600 vivas y corrientes. UNIQUE (vehiculo_id) WHERE borrado_en IS NULL -> se cumple HOY a 1738/1738 y esta MAL. Prohibe que un vehiculo tenga a la vez una version cerrada y una abierta, que es exactamente lo que versionar ES. Pasaria todos los gates que a cualquiera se le ocurrieran y se rompe con la primera escritura versionada correcta. UNIQUE (vehiculo_id) WHERE borrado_en IS NULL AND fecha_vigencia_hasta IS NULL -> una version CORRIENTE por vehiculo, se cumple a 1600/1600, y su predicado es IDENTICO al del indice parcial que ya existe. Esta es la unica defendible si alguna vez se escribe. La aritmetica lo cierra: 1600 corrientes-vivas + 138 cerradas-vivas = 1738 = la flota viva, y los dos conjuntos son DISJUNTOS por vehiculo - 1600 es exactamente la poblacion ALTA y 138 exactamente la BAJA. O sea que el 1:1 de hoy es una coincidencia de que los vehiculos de baja no tienen version abierta, no una regla. NINGUNA DE LAS DOS ES TRABAJO Y NINGUNA ESTA PROPUESTA. Se registra cual seria la correcta SI alguna vez se escribe, precisamente porque la equivocada mide perfecto. LA REGLA GENERAL, que es lo unico de todo esto que hay que recordar: UN 1:1 SOSTENIDO POR DATOS NO IMPLICA QUE UNA RESTRICCION DE UNICIDAD SEA EL ARREGLO. Puede significar igual de bien que la tabla PERMITE muchos y hoy tiene uno porque la funcionalidad no se usa. Antes de proponer unicidad hay que leer que dicen las OTRAS columnas y los indices parciales sobre la intencion del diseno - aca el par de vigencia y ix_vdc_vehiculo_vigente dicen "muchas filas, una corriente", y un UNIQUE ingenuo habria codificado lo contrario midiendo perfecto. Misma leccion que el cambio de enforcement de MOVILBA-42, una tabla mas alla.
• wi-cli-venus assigned · 6w ago
  db02-mba-l-cc / db
• wi-cli-venus note · 6w ago
  Re-medido 2026-08-31 05:35 por db02-mba-l-cc en los DOS entornos. La cifra del titulo (136 vivas con estado_id NULL, 136 de 1738 publicadas) ya no es la de hoy y no es del entorno que sugiere: PROD 10.78.42.168/movilba = 308 filas vivas de vehiculo_historial con estado_id NULL sobre 1740, y v_vehiculos_lineas_entidades publica 956 con estado nulo sobre 2388. DEV 10.9.10.54/movilba_dev = 309 sobre 1763, vista publica 950 sobre 2393. O sea el agujero es el DOBLE de lo que dice el item y es igual de grande en los dos lados, asi que no es deriva de dev. El defecto no cambio de forma, cambio de tamano - re-medir antes de dimensionar el arreglo. Contexto que agrega urgencia: esa vista ahora expone cuit (MOVILBA-144) y es la fuente comoda del payload de Rendiciones, o sea que queda a un JOIN de parecer tambien la fuente de estado. Decision de Elazar vigente: estado se sirve de vdc.estado_id, NUNCA de esta vista.
• wi-cli-venus statusChanged · 6w ago
• wi-cli-venus note · 6w ago
  RE-MEDIDO 2026-09-03 en PROD (10.78.42.168) y DEV (10.9.10.54), SELECT, db02-mba-l-cc. Las tres cifras del item estan vencidas y, mas importante, la DESCOMPOSICION es otra. CIFRAS DE HOY. PROD: 4225 filas de historial, 2621 con estado_id NULL, 308 de esas VIVAS, 1740 vivas en total. La vista v_vehiculos_lineas_entidades tiene 2388 filas (el item dice 1738) y 956 con estado NULL (el item dice 136). DEV: 4340 / 2711 / 309 vivas / 1765; vista 2394 filas y 950 nulas. EL 956 NO SALE DE DONDE DICE EL ITEM. Descomposicion, casi identica en los dos entornos - PROD 956 = 648 + 308, DEV 950 = 642 + 308: 648 vehiculos NO TIENEN NINGUNA FILA DE HISTORIAL VIVA. El NULL es del LEFT JOIN, no de un estado sin sellar. Es la causa MAYORITARIA y el item no la menciona. 308 son filas elegidas cuyo estado_id esta efectivamente en NULL. Ese es el sujeto real del item, y hoy son 308, no 136. Y DE ESAS 308, SOLO 175 SON UN HUECO. En PROD 175 estan ABIERTAS (fecha_baja vacia) y 133 estan CERRADAS. Una fila CERRADA sin estado_id es exactamente lo que exige el invariante de MOVILBA-212 ('una fila viva con fecha_baja cargada no puede aportar estado corriente'), asi que contar las 308 como defecto sobrecuenta en 133: mezcla filas correctas-por-invariante con filas que si son un hueco. El hueco real es 175 filas abiertas que describen un periodo vigente y no dicen el estado. RESPUESTA A LA PRIMERA PREGUNTA DEL ITEM (nadie la habia trazado): NO HAY NINGUNA SUPERFICIE QUE RENDERICE ESTO. v_vehiculos_lineas_entidades tiene un solo consumidor en dev/dev, src/repositories/rendiciones.ts, y ahi se seleccionan le.cuit, le.numero_linea, le.expte_alta y le.entidad_id - le.estado_id NO se selecciona nunca. El estado que sirve Rendiciones sale de d.estado_actual_id (la ficha) via oe.valor_opcion, y hay un comentario de cabecera (lineas 7-18) que prohibe explicitamente usar el estado de esta vista. O sea: es DEUDA DE DATOS y una COLUMNA MUERTA, no un defecto visible. RECOMENDACION: sacar estado_id de v_vehiculos_lineas_entidades. Su unico consumidor deliberadamente no la usa y su derivacion es la MISMA defectuosa de MOVILBA-147/212 (publica el sello de un periodo cerrado). Mientras la columna exista, cualquiera que la cablee hereda los dos defectos de una vez. RESPUESTA A LA SEGUNDA PREGUNTA (por que hay filas vivas sin estado): ninguna viene de la app. Las 308 de PROD son todas de import/migracion: 170 de 'db-mba-l-cc-snapshot5-nuevos-eslabones-2026-08-25' (las 170 ABIERTAS, identicas en DEV), 131 de 'import-movilba-19' (las 131 CERRADAS), 2 de 'Elazar (GO 2026-08-25 via db02-mba-l-ca)', 2 de 'movilba-104-prod', 2 de 'import-rutap-2026-08-14-prod', 1 de 'import-movilba-24'. En DEV el bloque de 131 lo escribio 'import-rutap-faltantes-2026-08-21-dev'. El hueco de 170 filas abiertas es de snapshot5 y es el mismo en los dos entornos. NO ES otra cara del atraso de libro de MOVILBA-155: son filas escritas por nuestros propios imports, no altas de Eugenia que falten. NO EJERCITADO: no medi si los 648 sin historial vivo deberian tenerlo; no abri las 170 de snapshot5 una por una; cero escrituras.
• wi-cli-venus completed · 6w ago
  Las dos preguntas del item quedaron contestadas el 2026-09-03 (ver nota del mismo dia). (1) NADA renderiza esas filas: v_vehiculos_lineas_entidades.estado_id no se selecciona en ninguno de sus DOS consumidores (rendiciones.ts y vehiculos.ts, este ultimo por el binding drizzle), asi que es deuda de dato sobre una columna muerta y no un defecto visible. (2) Las filas vivas sin estado son todas de import/migracion, ninguna de la app; 170 de ellas las escribio snapshot5-nuevos-eslabones-2026-08-25. Cifras corregidas: 956 nulos de la vista = 648 sin fila viva + 308 con la fila sellada en NULL, y de esos 308 solo 175 son un hueco (133 son filas CERRADAS que DEBEN tener NULL segun el invariante de MOVILBA-212). El trabajo remanente vive en otros items y no en este: sacar la columna muerta es MOVILBA-214 (diferido a post-go-live por coder02), y completar las 170 filas de snapshot5 con linea y estado es MOVILBA-216. Cierro para no medir lo mismo dos veces.