movilba
MOVILBA-470
v_vehiculo_historial_actual devuelve la fila de cierre de baja como periodo vigente
Done normal
dmdb04-mba-l-ca
AC363OK (DEV): rutap.v_vehiculo_historial_actual selecciona el id 193864 - fila origen=app, fecha_alta=fecha_baja=2026-09-10, expte_alta NULL, expte_baja EX-2026-40908802, escrita por app-editar-colectivo. Esa fila NO es un periodo de vigencia: es el cierre de la baja. El libro (rutap.rutap_rows, snapshot 16) tiene 4 filas para el dominio y ninguna alta el 10/09. v_vehiculos_ciclo_actual SI la excluye por FORMA (origen=app AND fecha_baja NOT NULL AND btrim(expte_alta) vacio AND btrim(expte_baja) no vacio) y devuelve el alta real: 232263, import, 2026-08-31, EX-2026-39238536 (db02, DEV; PROD no tiene la fila de cierre). La misma forma esta reconocida en src/lib/historial-vehiculo.ts (esEventoDeBaja, MOVILBA-451) y en el cuerpo de v_vehiculos_ciclo_actual, y ninguna capa se entera de la otra. Consumidores de la vista sin exclusion: src/repositories/vehiculos.ts:389-390 (fechaVigenciaDesde/expteAlta del detalle, que son el FALLBACK del panel Estado Actual cuando cicloActual es null), src/repositories/vehiculos.ts:188, src/repositories/parque-movil.ts:131 (Expediente vigente / tramite del parque). Poblacion hoy: db02 midio 0 vehiculos en DEV y 0 en PROD con fecha_alta_actual NULL teniendo historial con fecha_alta, asi que el fallback del panel no esta disparando hoy. La vista igual devuelve la fila de cierre como vigente para todo consumidor que la lea directo. Arreglo: la PRIMITIVA, no una cuarta copia del chequeo de forma en la app. DDL en DEV via db02 con pg_depend enumerado antes, nunca CASCADE, pg_get_viewdef de DEV y PROD comparado antes de escribir cuerpo nuevo. PROD pide GO fresco. Al quedar la vista correcta, la cadena de fallback de page.tsx:1450-1460 y :877-888 sobra y se borra.
Activity
-
audit-mba-l-cc, 2026-09-17: revisó los 3 consumidores. Ninguno quiere la lectura cruda 'la fila mas reciente sea cual sea'. - src/repositories/vehiculos.ts:188 (LATERAL periodo_veh): el comentario dice 'canonical normalized period' - quiere el periodo de negocio vigente. - src/repositories/vehiculos.ts:389-418 (overlay periodoVigente): se arma del mismo LATERAL, no es independiente; hereda lo que se arregle en la primitiva. - src/repositories/parque-movil.ts:131 (vhJoin): alimenta el campo 'expediente' del OpenAPI publicado, REQUERIDO por contrato (§3.2). Una fila de cierre de baja tiene expte_alta NULL, asi que hoy esto le puede entregar a SOTAMIT un expediente nulo para un vehiculo que SI tiene uno en el periodo anterior. Mismo defecto, pero hacia afuera. Los ORDER BY de desempate de las tres son para otro problema (colapso multi-dominio en vehiculos renombrados) y no los toca este arreglo. Veredicto de audit: arreglar la primitiva y BORRAR la cadena de fallback. UNA vista corregida, no dos vistas con nombres distintos. Pendiente antes de cualquier escritura: db02 con pg_get_viewdef DEV/PROD + md5, pg_depend, cuerpo propuesto y cuantos vehiculos cambian de fila vigente en cada base. Ese ultimo numero decide si es arreglo silencioso o decision de Elazar - y ahora tambien mide cuantos expedientes nulos salieron por la API externa.
-
db02-mba-l-cc, 2026-09-17, medicion final read-only: - Radio vivo: DEV 7 vehiculos (AA013AD, AA480BB, AC213TA, AC363OK, AF894KI, AG202SZ, AG232XB), PROD 0. - De esos 7, 7/7 tienen expte_alta NO NULO en el periodo que devolveria la vista corregida. Cero falsos positivos: no hay ningun caso donde el expediente siga siendo nulo despues del arreglo. Son 7 expedientes que existen en el dato y que el OpenAPI publicado reporta hoy como nulos (campo requerido por contrato, src/repositories/parque-movil.ts:131). - Conteo de filas: DEV 2430 -> 2430, PROD 2413 -> 2413. Nadie pierde su fila vigente; solo cambia CUAL fila se elige, en esos 7. - PROD 0 no es 'PROD esta sano': el cuerpo de PROD tampoco tiene la exclusion por forma, asi que el defecto dispara apenas PROD reciba su primera baja escrita desde la app. Esta armado, no ausente. Hallazgo aparte, del mismo barrido: la vista NO expone en su SELECT final (se pierde entre el CTE y el select externo, en las DOS bases). Un consumidor que lea solo las columnas de la vista no puede detectar la forma de cierre ni queriendo; db02 tuvo que hacer join de vuelta a rutap.vehiculo_historial_normalizado por id para medirlo. Decision tomada (coder03): el arreglo FILTRA adentro y NO agrega al SELECT. Exponerlo invitaria a una cuarta capa re-derivando la forma, que es exactamente lo que este ticket viene a borrar. El contrato pasa a ser 'esta vista devuelve el periodo vigente de negocio', no 'devuelve una fila y vos fijate'.
-
db02-mba-l-cc, 2026-09-17, medicion final read-only: - Radio vivo: DEV 7 vehiculos (AA013AD, AA480BB, AC213TA, AC363OK, AF894KI, AG202SZ, AG232XB), PROD 0. - De esos 7, 7/7 tienen expte_alta NO NULO en el periodo que devolveria la vista corregida. Cero falsos positivos: no hay ningun caso donde el expediente siga siendo nulo despues del arreglo. Son 7 expedientes que existen en el dato y que el OpenAPI publicado reporta hoy como nulos (campo requerido por contrato, src/repositories/parque-movil.ts:131). - Conteo de filas: DEV 2430 -> 2430, PROD 2413 -> 2413. Nadie pierde su fila vigente; solo cambia CUAL fila se elige, en esos 7. - PROD 0 no es "PROD esta sano": el cuerpo de PROD tampoco tiene la exclusion por forma, asi que el defecto dispara apenas PROD reciba su primera baja escrita desde la app. Esta armado, no ausente. Hallazgo aparte, del mismo barrido: la vista NO expone la columna origen en su SELECT final (se pierde entre el CTE y el select externo, en las DOS bases). Un consumidor que lea solo las columnas de la vista no puede detectar la forma de cierre ni queriendo; db02 tuvo que hacer join de vuelta a rutap.vehiculo_historial_normalizado por id para medirlo. Decision tomada (coder03): el arreglo FILTRA adentro y NO agrega origen al SELECT. Exponerlo invitaria a una cuarta capa re-derivando la forma, que es exactamente lo que este ticket viene a borrar. El contrato pasa a ser "esta vista devuelve el periodo vigente de negocio", no "devuelve una fila y vos fijate".
-
Correccion de registro: la nota de las 00:27:36 quedo mutilada (perdio dos veces la palabra 'origen' por una expansion de shell) y esta SUPERSEDED por la de las 00:27:49, que es la buena. Leer esa.
-
DEV APLICADO por db02 (2026-09-17 21:34 ART) contra baseline re-leido (md5 9284f23e sin cambios antes del apply); md5 nuevo a35895c0a18849a3c5ec4439ba757439. Verificacion literal: 2430 filas / 0 filas con forma de cierre elegidas / 7 dominios con expte_alta no nulo, ids iguales a la simulacion previa. App: v5.5.211 (07727d74) archivo de migracion; v5.5.212 (6926deb3) page.tsx Estado Actual lee SOLO el ciclo, sin fallback a colectivoData/vehiculo (que leian la vista defectuosa); README de migraciones indexado. Ambos diffs en audit. NO ejercido: la ficha (sin login dev01 en ningun carril) ni /api/v1/parque/vehiculos para los 7 (x-api-key hasheada en api_keys, sin plaintext disponible). PROD: congelado detras de MOVILBA-471, sin GO pedido.
-
audit sobre 6926deb3: la premisa de 'observaciones del periodo' era falsa por mecanismo. colectivoData.observaciones NO lee la vista historial: es la columna a nivel vehiculo de vehiculos_datos_colectivos (editable desde la app, vehiculos.ts:1216), una TERCERA fuente. La nota del periodo vigente llega por el overlay periodoVigente como vehiculo.observaciones (vehiculos.ts:392/417). Medido DEV post-apply: VDC.observaciones distinta de la del periodo en 101/2430 vehiculos, con strings de QA adentro (AA013AD). Decision A tomada: la tarjeta Estado Actual habla del tramite, asi que sin baja lee vehiculo.observaciones y deja de leer VDC. Shipeado v5.5.213, pantalla y PDF. La lectura de VDC ya no aparece en la tarjeta.
-
audit sobre 605d185d: la superposicion periodoVigente (src/repositories/vehiculos.ts) se aplicaba SOLO con fila en v_vehiculo_historial_actual; sin fila, los 4 campos (fechaVigenciaDesde, expteAlta, expteBaja, observaciones) caian a las columnas homonimas de VDC que trae v_vehiculos_detalle - el mismo fallback silencioso a otra fuente, una capa mas abajo. DEV: 0 vehiculos vivos sin fila (dormido, no muerto). Arreglo shipeado v5.5.214: la superposicion es incondicional, sin periodo = NULL en los 4. Los lectores de VDC.observaciones que quedan (export externo, editor, archivo, writer :890) van en MOVILBA-472 (decision de Elazar: contrato del export).
-
2026-09-17 22:43 ART OBSERVED on dev01 v5.5.215 by proxy-mba-w-cc (live authenticated browser), 7/7 dominios of the 470 population. Estado Actual card now shows the book's alta on every one: AC363OK 31/08/2026 EX-2026-39238536; AA480BB 18/08/2025 EX-2025-34090500; AC213TA 31/08/2026 EX-2026-39142761; AF894KI 05/06/2026 EX-2026-26749058; AG202SZ and AG232XB 01/04/2026 "Res. SECT 56/2026"; AA013AD 05/02/2026 EX-2026-07797873. AC363OK PDF (2026-09-17-2242-movilba-AC363OK-reporte01.pdf) identical to the page. Item 13's last sentence is no longer derived. Each card also shows the app-recorded baja (10/09, 11/09, 15/09; AA013AD 08/09) - expected: the baja events are the DEV test closures the ficha resolves separately from the alta. One inconsistency handed to db02: AA013AD top-level "Estado actual: Alta" while the card shows Baja registrada el 08/09/2026 (event 177666 still present after the 435 reconciliation set estado back to ALTA).
-
coder03assistant-mba-l-ca | 2026-09-24 04:11:38 ART | DEV movilba_dev / PROD movilba installed rutap.v_vehiculo_historial_actual both filter app closure rows by origen, fecha_baja, empty expte_alta and present expte_baja. Current repositories still consume view; requested deletion of redundant page fallback chain not verified, and dev/main vehiculos.ts differ. View half complete; keep item open.
-
db03-mba-l-cc
-
db04-mba-l-ca
-
db04-mba-l-ca 2026-10-01 12:46 ART. Verified installed rutap.v_vehiculo_historial_actual in PROD movilba and DEV movilba_dev with pg_get_viewdef: both WHERE clauses exclude app closure shape (origen app, fecha_baja present, blank expte_alta, present expte_baja). PROD has 0 such unsoftdeleted history rows and view selects 0; DEV has 24 such rows and view selects 0. AC363OK resolves to alta 2026-08-31 / EX-2026-39238536 in both bases. Current src/app/vehiculos/[dominio]/page.tsx Estado Actual card lines1465-1490 reads cicloActual only; no old vehiculo/VDC fallback chain. The view and page outcomes requested by this item are present; no DB or repo write made in this sweep. Current direct API/browser rendering was not re-exercised, but prior ticket event records authenticated browser/PDF verification on seven affected domains.
-
audit pass: Verified db04's PROD/DEV pg_get_viewdef comparison claim via static code check: page.tsx:1455-1490 Estado Actual reads cicloActual only, no fallback to colectivoData/vehiculo. Comment at 1461 cites MOVILBA-470 explicitly.
payload
{"scope":"Verified db04's PROD/DEV pg_get_viewdef comparison claim via static code check: page.tsx:1455-1490 Estado Actual reads cicloActual only, no fallback to colectivoData/vehiculo. Comment at 1461 cites MOVILBA-470 explicitly.","outcome":"pass","evidence":"No DB creds from this lane - relies on db04's pg_get_viewdef + SELECT-only counts (PROD 0, DEV 24 excluded). Code-side closure confirmed independently. db04 itself flagged live browser/API re-render as unexercised this sweep; prior 2026-09-17 browser verification on 7/7 domains stands as last live check.","reportRef":null} -
audit pass: Verified page.tsx:1455-1490 Estado Actual reads cicloActual only, no fallback to colectivoData/vehiculo, matches db04's claim.
payload
{"scope":"Verified page.tsx:1455-1490 Estado Actual reads cicloActual only, no fallback to colectivoData/vehiculo, matches db04's claim.","outcome":"pass","evidence":"No DB creds from this lane - relies on db04's pg_get_viewdef+count comparison (PROD 0, DEV 24 excluded). Code-side closure confirmed independently. Live browser/API re-render unexercised this sweep; prior 09-17 verification on 7/7 domains stands.","reportRef":null} -
completed
bug
4w ago by wi-cli-venus
2w ago
2026-10-01 15:36