vdc.observaciones no sigue al periodo vigente: 22 dominios en PROD llevan el texto de un periodo ANTERIOR y 10 llevan texto que no esta en el libro vigente
Medido por db04-mba-l-ca sobre PROD (movilba, snapshot 5, import vivo), SELECT-only, 2026-09-23. Evidencia durable: /data-lezama/movilba/evidencia/MOVILBA-537/2026-09-23-db04-period-pairs.{sql,json} y 2026-09-23-db04-normalized-census.{sql,json}. PARTIDA DEL HALLAZGO. Se partieron las 50 filas de vdc.observaciones que no tenian match byte a byte contra el libro, usando una normalizacion declarada (borrar comas y puntos, colapsar espacios, trim; case y acentos intactos): 18 son diferencias SOLO de puntuacion contra el periodo canonico, 22 matchean un periodo NO canonico del mismo dominio, y 10 no matchean en ningun lado. El total sin partir no sostenia ni el borrado de la columna ni su conservacion - ver la trampa de metodo correspondiente. LOS 22 SON EL DEFECTO. Cada uno de los 22 dominios matchea las posiciones cronologicas 1 y 2 y NO la canonica. Matchea DOS porque esas dos filas comparten el mismo texto entre si, no porque haya ambiguedad de procedencia. En 21 de 22 la canonica es la posicion 3; AF431KK es posicion 4 y no matchea ninguna de sus dos previas inmediatas. TODAS las filas involucradas son origen=import, snapshot 5: no hay ninguna fila de app en el medio, asi que esto no es un overlay ni una edicion de usuario. O sea vdc.observaciones quedo estampado con el texto de un periodo viejo y el materializador no lo refresco al avanzar el periodo vigente. DATO QUE HAY QUE EXPLICAR ANTES DE ARREGLAR: los 22 comparten EXACTAMENTE el mismo par de fechas en las posiciones 1 y 2 - 2025-07-08..2025-11-28 y 2025-11-28..2026-01-01 - sobre vehiculos que no tienen nada que ver entre si. Fechas identicas en 22 vehiculos no son fechas de negocio; parecen bordes de snapshot. Antes de tocar el materializador hay que decidir si esas dos filas son periodos legitimos del libro o filas fabricadas por el import, porque si son fabricadas el defecto esta un paso mas arriba y arreglar la materializacion lo tapa. LOS 10 SON OTRA COSA. Texto que no aparece en el libro vigente bajo ninguna normalizacion. Nueve dicen 'Se modificaron datos[,] a pedido de la empresa' o 'a solicitud de la empresa' - pasado - donde el libro escribe 'Se modifican datos a pedido de la empresa' - presente. El decimo, AB267UM, dice 'Se modifico Identidad por declaracion de la empresa'. Dominios: AB017PX, AB267UM, AF756OK, AF853LN, AF964LQ, OOT547, OZP248, PMH980, PMH992, PMI006. La conjugacion en pasado sugiere que no salieron del libro vigente, pero eso no esta medido: probar el origen es parte del ticket, no una premisa. LOS 18 NO SON UN DEFECTO. Puntuacion contra el periodo correcto. No se normaliza nada en la base por esto. APARTE, NO ES DE ESTE TICKET: el patron coma-por-punto del libro (S,A, en vez de S.A.) esta CONFINADO a observaciones - 316 celdas, 3 valores distintos, cero en las otras 52 columnas fuente del libro. Local, no transversal. Que se haga con eso se decide despues y no aca. NO HACER TODAVIA: no se toca el materializador ni se borra la columna hasta resolver la pregunta de las dos fechas uniformes.
Activity
-
BLOQUEO LEVANTADO - mi sospecha era equivocada. Medido por db03-mba-l-cc sobre PROD, SELECT-only, snapshot 5 (2026-09-19-0648-parque-rutap-corrected.xlsx): las dos fechas uniformes ESTAN EN EL ARCHIVO DEL LIBRO, no las pone el importador. Evidencia en tres capas que coinciden: el xlsx (hoja Base, celdas datetime de Excel, md5 del snapshot) tiene fecha_alta=2025-07-08 en 1642 celdas y los dos pares en 33 y 25; rutap.rutap_rows crudo tiene los mismos conteos; el normalizado tambien, con 0 mismatches sobre 5528 filas de import. Ninguna de las dos fechas coincide con fecha_descarga (2026-09-19T06:48) ni con importado_en (2026-09-19T14:17:23), que son las unicas fechas del registro de snapshots. Los cuerpos INSTALADOS confirman que no hay fallback: proyectar_snapshot saca fecha_alta/fecha_baja solo de la celda cruda con un CASE sobre el patron ISO, sin COALESCE y sin current_date/now() cerca de esas columnas; materializar_snapshot_raices agrega un round-trip to_char(to_date(x))=x y ABORTA si una celda no vacia no parsea; una celda vacia da NULL, no un default. reconciliar_snapshot copia esas mismas fechas a vdc.fecha_vigencia_desde/hasta. O sea 2025-07-08 en ~30% de las filas es una convencion del libro de Eugenia, no un borde de snapshot. Por que el libro hace eso no se contesta desde la base y no se investigo mas alla del archivo. CONSECUENCIA: el defecto de los 22 es REAL y esta en la materializacion de vdc.observaciones, no un paso mas arriba. Se puede trabajar. Lo que falta medir es cual funcion escribe vdc.observaciones y DESDE QUE FILA - las fechas se copian del periodo correcto pero el texto no, asi que los dos campos de vdc no salen de la misma fila. Cobertura de esta medicion: no mira los 22 casos de observaciones en si (son de db04) y no hay snapshots viejos que mirar - existe uno solo.
-
REENCUADRE IMPORTANTE - baja la severidad, no cierra el ticket. Censo de coder04-mba-l-ca sobre dev 20fcf2ce: CERO lectores ejecutables de vehiculos_datos_colectivos.observaciones en src/ y tools/. Las cuatro superficies leen rutap.v_vehiculo_historial_actual.observaciones, no la columna de vdc: repositories/vehiculos.ts:472,499 la superpone al DTO; la pagina y el PDF en app/vehiculos/[dominio]/page.tsx:913-930 y 1494-1510 consumen ese overlay; el export lee v_vehiculos_export, que en drizzle/schema.ts:2829-2833 define observaciones como h.observaciones de esa misma vista; y /api/v1 en repositories/parque-movil.ts:154-167,237-238 saca current_h.observaciones de ahi tambien - su lateral de VDC no selecciona observaciones. El formulario de edicion no tiene campo de observaciones de VDC: manda motivoTramite. src/types/vehiculos.ts:362 ya dejaba constancia de que la columna de VDC se habia sacado por 472. CONSECUENCIA: las 22 filas rancias y las 10 sin match viven en una columna que ninguna superficie muestra. No hay usuario viendo un dato viejo hoy. El defecto de materializacion sigue siendo real - la columna existe, el import la escribe, y esta desalineada con el periodo vigente - pero es deuda, no un dato incorrecto publicado. CAMBIA LA PREGUNTA. Ya no es 'como arreglamos la materializacion' sino 'por que existe esta columna'. Si nada la lee y v_vehiculo_historial_actual es la fuente real, el arreglo probablemente sea retirarla, no sincronizarla - y eso hace converger DEV (donde no existe) con PROD (donde si), que era justo lo que 472 tenia sin resolver. FALTA MEDIR ANTES DE DECIDIR: el censo fue del CODIGO. Falta el censo de la BASE - si alguna vista, funcion o trigger de PROD lee vdc.observaciones. Un lector en SQL no aparece en un git-grep del repo. Pedido a db03-mba-l-cc junto con el censo de escritores. Hasta que ese numero este, no se retira nada. Nota de metodo: el hallazgo original se midio sobre la columna equivocada. vdc.observaciones no es lo que ve el usuario. La comparacion util contra el libro es la de la vista de periodo vigente, que todavia no se corrio.
-
PERDIDA REAL DEL DROP: 11 avisos genericos, nada sustantivo. Medido por db03-mba-l-cc contra el ARCHIVO del libro (snapshot 5, 2026-09-19-0648, todas las hojas, normalizando puntuacion/caso/acentos), no contra las filas importadas. De las 1545 filas pobladas de vdc.observaciones en PROD: 1233 recuperables de la fila de import vigente, 261 de otra fila del mismo vehiculo, y de las 51 que parecian irrecuperables, 40 SI estan en el libro. Quedan 11: AB017PX, AB267UM, AF756OK, AF853LN, AF964LQ, AG986KG, OOT547, OZP248, PMH980, PMH992, PMI006 - todas la formula 'Se modific(aron/an) datos/identidad ... a pedido/solicitud de la empresa'. AG202SZ y AC966VL, los dos que nos preocupaban, NO son perdida. La cesion a T.A.R.S.A. de 3626 AC966VL esta en el libro, columna Modif: 'Se autorizo cesion del permiso de la empresa G,T,Guido S,A, a T,A,R,S,A,'. LA MISMA TRAMPA, TERCERA VEZ EN ESTE TICKET. El byte-compare anterior no la encontro porque el libro escribe comas donde el texto de vdc tiene puntos - G,T,Guido contra G.T.Guido. Esa es la corrupcion coma-por-punto confinada a observaciones que medimos mas arriba, y volvio a inflar un conteo de perdida: 51 irrecuperables eran 11. Antes ya habia convertido 50 'sin match' en 18/22/10. Regla que sale de aca: un conteo de perdida derivado de igualdad exacta se re-mide normalizado ANTES de ponerlo delante de alguien que tiene que decidir sobre el. Yo le pase 51 a Elazar y el numero era 11. Cobertura de esta medicion: el archivo del libro entero, todas las hojas, filas que llevan el dominio. No se chequeo audit_log. ESTADO: la perdida esta acotada y nombrada. El DROP sigue necesitando la palabra de Elazar porque es una columna POBLADA, que es carve-out explicito de la regla pre-go-live, no importa que la perdida sea chica.
-
db03-mba-l-cc
-
db04-mba-l-ca
-
db04-mba-l-ca 2026-10-01 12:42 ART, PROD SELECT-only after snapshot8: public.vehiculos_datos_colectivos.observaciones still exists and 1545 rows carry nonblank text; current rutap.v_vehiculo_historial_actual has 2419 rows/2419 distinct vehiculo_id. Legacy VDC text is byte-distinct from current-period h.observaciones on 1186 joined rows (this raw count includes punctuation/null/period changes; it is NOT 1186 business mismatches). Installed pg_get_viewdef shows public.v_vehiculos_export reads periodo_veh.observaciones, not vdc.observaciones; public.v_vehiculos_detalle reads cur_fa.observaciones, not vdc.observaciones. Thus the original 22/10 stale VDC values are not emitted by those two current views. Physical VDC column still exists; do not DROP populated text on this item without the separate MOVILBA-537 decision. This measurement narrows 562 to unused legacy storage/materialization, not a live display defect.
-
db04-mba-l-ca 2026-10-01 12:50 ART. PROD snapshot8 measurement on preceding progress event: 1545 nonblank rows remain in populated vdc.observaciones, while installed v_vehiculos_export and v_vehiculos_detalle both source current-period observaciones, not VDC. The user-visible projection defect is already removed; the remaining choice is whether to keep synchronizing this unused legacy column or physically retire it. MOVILBA-537 carries the populated-column DROP and requires Elazar’s explicit choice; do not alter or delete the 1545 texts under 562 before that decision.
-
cleared: db04-mba-l-ca 2026-10-01 12:50 ART. PROD snapshot8 measurement on preceding progress event: 1545 nonblank rows remain in populated vdc.observaciones, while installed v_vehiculos_export and v_vehiculos_detalle both source current-period observaciones, not VDC. The user-visible projection defect is already removed; the remaining choice is whether to keep synchronizing this unused legacy column or physically retire it. MOVILBA-537 carries the populated-column DROP and requires Elazar’s explicit choice; do not alter or delete the 1545 texts under 562 before that decision.
-
Duplicate of MOVILBA-537's populated public.vehiculos_datos_colectivos.observaciones retirement decision. PROD snapshot 8: 1545 nonblank legacy VDC rows, with current-period observaciones already supplied to public.v_vehiculos_export and public.v_vehiculos_detalle from history; no user-visible stale projection remains under 562. The original 22 prior-period and 10 absent-text cases are legacy-column contents, not a separate live display defect. MOVILBA-537 retains the populated-column DROP decision and loss accounting; no data or DDL changed here.