La app LEE entidad/linea de public.vehiculo_historial y las ESCRIBE en rutap.vehiculo_historial_normalizado

Sub-tickets — 1/1 done

Activity

• wi-cli-venus created · 5w ago
• wi-cli-venus assigned · 5w ago
  coder02-mba-l-cc
• wi-cli-venus priorityChanged · 5w ago
  0
• wi-cli-venus progress · 5w ago
  2026-09-07 15:50 - CONFIRMADO EN CAMPO por una usuaria real, no por sonda: Eugenia sobre FB444EP (id 6723), dev01 5.5.47. La ficha no muestra LINEA ni ENTIDAD; las carga por edicion y sigue sin mostrarlas. MEDIDO por db02-mba-l-cc en movilba_dev, SELECT-only: - public.vehiculo_historial: 0 filas para 6723. - rutap.vehiculo_historial_normalizado: 3 filas (80587 alta, 80588/80589 ediciones), TODAS con entidad_id 41 y linea_id 132, origen=app, borrado_en NULL. - El dato NO se perdio. No hay reparacion de datos pendiente. CADENA, verbatim de pg_get_viewdef: v_vehiculos_detalle toma entidad de v_vehiculos_entidad_actual y linea de v_vehiculos_linea_actual; las dos son pasamanos de v_vehiculos_hist_ultimo, cuyo FROM es public.vehiculo_historial. El array historial es un subquery FROM vehiculo_historial, de ahi el []. NINGUNA vista filtra: el unico WHERE es v.borrado_en IS NULL. La fila nunca estuvo en la tabla que se lee. HIPOTESIS MIA REFUTADA: postule un join a snapshot RUTAP o un predicado de periodo que un vehiculo sin libro no pudiera satisfacer. No hay predicado alguno. La causa es mas simple y peor. COBERTURA (esta es la que decide el arreglo): de 2416 vehiculos vivos, rutap.v_vehiculo_historial_actual resuelve 2411 y v_vehiculos_hist_ultimo 2412. NINGUNO contiene al otro: 5 vivos estan solo en la vieja (PAN219, ZZ001ZZ, ZZ002ZZ, DHU474, AA111EE) y 4 solo en rutap (ZZ999XX, ZZ998YY, ZZ997WW, FB444EP). Un repunte directo arregla 4 y ROMPE 5. Ademas, sobre la interseccion de 2407: entidad_id difiere en 11 y linea_id en 11, y en TODAS rutap tiene NULL donde la vieja tiene valor. Los 16 vehiculos son estado_derivado BAJA: la vieja conserva la ultima entidad/linea conocida y rutap la suelta. Un repunte directo borraria esas etiquetas de 16 pantallas. CONCLUSION: el arreglo es COALESCE por COLUMNA (rutap primero, vieja de respaldo), no un repunte ni un UNION de filas. ALCANCE, medido: la lista tambien esta rota. v_vehiculos_list ya hace COALESCE(vea.entidad_id, hu.entidad_id) pero los dos brazos salen de la MISMA tabla vieja, asi que el coalesce no compra nada; FB444EP aparece ahi con entidad_id, entidad_nombre y numero_linea en NULL. _alta/_baja/_mantenimiento son filtros finos sobre v_vehiculos_list y heredan el defecto; FB444EP se ve en _alta con los mismos NULL. El formulario de edicion carga por v_vehiculos_lineas_entidades, que devuelve todo el lado historia en NULL: por eso el round-trip de Eugenia nunca mostro nada. PENDIENTE MIO, no medible desde la base: si rendiciones.ts:288 y :336 proyectan las columnas de entidad/linea de v_vehiculos_detalle o solo estado_actual_id. Decide si esa superficie esta afectada; no la voy a declarar afectada sin leerlo. DEFECTO SEPARADO, sin ticket: 80588 y 80589 llevan estado_id NULL - el camino de edicion no arrastra el estado al abrir el periodo sucesor. Hoy invisible; se volveria visible en el instante en que se repunte la lectura.
• wi-cli-venus progress · 5w ago
  2026-09-07 15:55 - PENDIENTE MIO RESUELTO, leido en rendiciones.ts: la superficie de rendiciones SI esta afectada, y de las dos consultas la peor no muestra vacio sino que DESAPARECE la fila. - listado por linea (:275-295): FROM v_vehiculos_lineas_entidades le JOIN v_vehiculos_detalle ... WHERE le.numero_linea = $1. Para un vehiculo creado por la app numero_linea es NULL, asi que el predicado NUNCA empareja: el colectivo no sale en el listado de rendiciones de su linea. No es una celda en blanco, es una ausencia. Proyecta ademas le.cuit, le.entidad_id, le.numero_linea y le.expte_alta, todas del lado roto. - ficha por dominio (:325-345): LEFT JOIN, asi que la fila sale pero con empresa {cuit:null, nombre:null, razon_social:null}, numero_linea null y expediente null. Esto sube la severidad: rendiciones es superficie de API consumida por fuera, no una pantalla interna, y el modo de falla del listado es omision silenciosa - la clase mas dificil de notar desde el otro lado. El COALESCE por columna en v_vehiculos_hist_ultimo tambien la arregla, porque las dos consultas cuelgan de v_vehiculos_lineas_entidades y de v_vehiculos_detalle, que resuelven ahi.
• wi-cli-venus progress · 5w ago
  2026-09-07 16:02 - RESUELTA la contradiccion que levanto proxy-mba-w-cc, y explica por que la pantalla se ve incoherente en vez de simplemente vacia. proxy vio 3 tramites renderizados en 'Historial del Vehiculo' de FB444EP, mientras db02 midio v_vehiculos_detalle.historial = []. Las dos mediciones son correctas: NO son la misma fuente. El panel de historial NO sale del campo historial de la vista. Sale de getVehiculoHistorial (actions/vehiculos.ts:86), que desde MOVILBA-204 llama a getRutapHistorialByChain, o sea la CAPA NORMALIZADA. El campo historial de v_vehiculos_detalle sigue existiendo y sigue saliendo de public.vehiculo_historial, pero esta pantalla ya no lo usa. CONSECUENCIA: la ficha esta MIGRADA A MEDIAS. El panel de tramites ya lee la capa nueva; entidad, linea y estado siguen leyendo la vieja. Por eso el sintoma que reporto Eugenia no es 'la pantalla esta vacia' sino algo mas confuso: la misma ficha LISTA los tres tramites del vehiculo y al mismo tiempo dice Linea 'No asignada' y Entidad 'No asignada', cuando la linea y la entidad estan justamente en esos tramites que esta mostrando. Un usuario ve la evidencia y la negacion en la misma pantalla. Tambien explica el Expediente poblado (EX-2026-39357754-GCABA-DGGSM) que proxy marco como contradictorio con el hallazgo de esta manana: ese expediente esta en la fila de alta de la capa normalizada, y llega por el mismo camino ya migrado. MI MODELO ESTABA INCOMPLETO, no equivocado: dije que la ficha entera leia la tabla vieja. Lee las dos. El arreglo de 08e46933 sigue siendo el correcto y su alcance no cambia - toca el resolutor de entidad/linea/estado, que es la mitad que quedo atras - pero la verificacion NO puede usar el panel de historial como senal: ese panel ya andaba antes del cambio y va a seguir andando despues, asi que si lo miro como control me da un falso positivo. Sin proxy abriendo el navegador esto no aparecia: las dos consultas de base eran consistentes con mi modelo equivocado.
• wi-cli-venus verified · 5w ago
  2026-09-07 16:12 - APLICADO EN DEV. Artefacto fa1c72b3 (commit 763f1f2f), aplicado por db03-mba-l-ca dentro de la ventana de GO, despues de que audit lo despejara nombrando ese sha256. Salida de las guardas del propio script: antes=2414, despues=2418, perdidos=0, pisados=0, control positivo derivado 2/2. FB444EP resuelve entidad 41 / linea 132, y la ficha muestra NUDO S.A. / linea 107. Los 5 que solo existen en la capa vieja siguen resueltos y los 16 BAJA conservan entidad/linea. db03 verifico desde una conexion NUEVA que la vista persistida contiene el FULL JOIN: no se dio por hecho el COMMIT. EL PRIMER INTENTO ABORTO Y ESO FUE LO MEJOR QUE PASO EN TODO EL TRABAJO. El control positivo era una lista de cuatro dominios literales y levanto con 'solo 2 de 4'. Diagnostico de db02 y audit, con valores y no con un conteo: de los cuatro, ZZ998YY tiene linea_id NULL y ZZ999XX tiene entidad_id NULL en su propia fila rank 1. No eran controles: eran dos vehiculos que cargan el dano del propio 315 - a ZZ999XX la fila 80583 le escribio NULL/NULL encima de entidad 41 / linea 21. Exigirle a la vista que devuelva un valor que no existe en la fuente no es un control positivo. Las guardas 1 a 4 son todas de no-dano y una vista que no arreglara nada las pasa todas. La 5 era la unica afirmacion falsificable del archivo y disparo. Si la hubiera escrito como aviso, esto se shipeaba y Eugenia seguia viendo los campos vacios. Lo reusable, por encima de este ticket: 1. Un control positivo cuyo sujeto ya fue danado por el defecto NO PUEDE PASAR NUNCA. Se elige el sujeto entre los que TIENEN algo que ganar. 2. La poblacion del control se DERIVA y se materializa ANTES del cambio. Computada despues es vacua por construccion: la vista nueva ya los resuelve, el filtro 'no resuelve' vacia el conjunto y la guarda pasa sin haber probado nada. 3. El archivo dice, guarda por guarda, cual PUEDE dispararse hoy y cual no. Hoy la 3 y la 4 no pueden. 4. El sujeto no se filtra por liveness. ZZ997WW es BAJA y es el unico miembro que prueba que entidad y linea sobreviven un periodo cerrado, que es la propiedad que protege a los 16 BAJA. El reflejo de filtrar bajas habria dejado el control en un solo miembro. NO se reparo ninguna fila para que la guarda pasara. 80583 y 80584 son la evidencia de 315 y 331. FALTA para cerrar: la verificacion en navegador (proxy-mba-w-cc, pedida contra su linea base de las 15:57), la verificacion independiente de db02 post-COMMIT, y el control de regresion sobre AA033TK, que es el que importa - la vista reescrita la resuelven 2400+ vehiculos.
• wi-cli-venus verified · 5w ago
  2026-09-07 22:57 - PATA DE NAVEGADOR CERRADA. Medido por proxy-mba-w-cc contra dev01 v5.5.53, con navegador real, despues de que Elazar le pasara una credencial corregida fuera del hub. Cuatro chequeos, los cuatro PASS: 1. Ficha de FB444EP: Linea 107 / Entidad NUDO S.A., las dos POBLADAS. En la pasada BEFORE decian 'No asignada'. Este es el defecto que reporto Eugenia Grosclaude y esta arreglado en pantalla. 2. Formulario de edicion de FB444EP: el combo Linea viene pre-seleccionado en '107' (value=132) y el de Entidad en 'NUDO S.A.' (value=41). No guardo. Nota de lectura: 107 es numero_linea y 132 es linea_id - el id y la etiqueta, no una discrepancia. 3. Listado con filtro Estado=Alta: la fila de FB444EP muestra Entidad 'NUDO S.A.' y Linea '107'. 4. CONTROL DE REGRESION, el que mas importaba: ficha de AA033TK sin cambios respecto del BEFORE - Estado Alta, Linea 109, Entidad TRANSPORTES NUEVE DE JULIO SAC. El COALESCE por columna no le movio nada a un vehiculo que ya resolvia bien por la tabla vieja. LO QUE ESTA PASADA NO CUBRE, y proxy lo dijo explicitamente: el panel 'Historial del Vehiculo' renderizo 3 filas sin error, pero NO se cuenta como confirmacion - ese panel lee por getRutapHistorialByChain (MOVILBA-204), o sea que esta medio migrado y es un control FALSO-POSITIVO para este arreglo. Tampoco se ejercito ninguna ESCRITURA: proxy no edito ni guardo nada, por su regla de no crear/editar/borrar vehiculos en dev01. Con esto 315 queda cerrado de los dos lados: base (db02, resolver DEV) y pantalla (proxy, navegador).
• wi-cli-venus assigned · 4w ago
  coder03-mba-l-cc / coder
• wi-cli-venus completed · 4w ago
  Cerrado por medicion en los DOS ambientes, 2026-09-18 (coder03). La division lectura/escritura ya no existe: public.v_vehiculos_hist_ultimo sale de v_vehiculo_historial_normalizado_actual en DEV y en PROD - o sea que la lectura quedo repuntada a la misma capa donde la app escribe, y sin el COALESCE por columna del plan del 09-07. El miedo de ese plan ('un repunte directo arregla 4 y ROMPE 5') NO se materializo: cobertura completa, 2430/2430 vehiculos vivos con fila en DEV y 2413/2413 en PROD, cero entidad_id null y cero linea_id null en los dos. De los 5 que solo vivian en la capa vieja (PAN219, ZZ001ZZ, ZZ002ZZ, DHU474, AA111EE) ninguno quedo sin resolver: DHU474 resuelve 57/75 en DEV y los otros cuatro ya no son vehiculos vivos; en PROD no existe ninguno de los cinco. La LIMITACION que quedaba documentada en la pantalla de edicion (campo que carga vacio no se puede vaciar, el usuario pide vacio y le queda el valor anterior) se cayo sola y NO por un arreglo: dependia de que la pantalla leyera de public.vehiculo_historial mientras la escritura iba a rutap. v_vehiculos_lineas_entidades, que es de donde carga esa pantalla, cuelga de v_vehiculos_hist_ultimo, asi que lo cargado y lo arrastrado son la misma fila. El mecanismo de omitir la clave se mantiene - sigue siendo lo unico que distingue 'no lo toque' de 'lo vacie a proposito'. Comentario corregido en el codigo, v5.5.237 970220a2: un comentario que declara una limitacion inexistente es premisa falsa para el que lo lea despues. Nota aparte para MOVILBA-318 (db02): su descripcion todavia cita 'v_vehiculos_hist_ultimo cubre 1740 de 2407 vivos en PROD', cifra que hoy es 2413/2413 - re-medir antes de planear el DROP.