movilba
MOVILBA-145
RUTAP importer stamps batch date into fecha_ultima_actualizacion
Done high
rmresearcher-mba-l-cc
Fix the RUTAP importer so vehiculos.fecha_ultima_actualizacion is the per-vehicle latest-modification expediente date, not an import-lot/batch timestamp. PROD evidence: only 3/2388 live vehicles match the max expediente date; values cluster on batch dates. Excludes Parodi/RUTAP source-date normalization, which Elazar is handling separately.
Activity
-
Owner started tracing the importer write path. Scope is only per-vehicle latest-modification expediente date; source-date normalization excluded.
-
db03 live DEV/PROD finding: fecha_ultima_actualizacion is nullable date DEFAULT CURRENT_DATE with no maintenance trigger; it is batch stamped. Do not backfill from vehiculo_historial.creado_en: it is audit/import time and 642 DEV / 648 PROD live vehicles have no history. The proposed backfill is withdrawn. Existing UI removal remains correct. Prospective business semantics require normalized authoritative source dates; validate after the next import under MOVILBA-146. API exposure is a separate contract decision.
-
Audit PASS (audit-mba-l-cc): safe to apply the guarded DEV/PROD migration when separately authorized. It removes only DEFAULT CURRENT_DATE, preserves existing values, and leaves prospective business-date validation to MOVILBA-146.
-
DEV applied under explicit GO: migration SHA256 04e854823f1615a4814a1feb2fa8b820ecbafe9b6ea124685105789ecbc254cb observed CURRENT_DATE, dropped the default, verified it absent, and committed. All 2,393 live stored values were preserved (range 2025-12-08..2026-08-28). No PROD action.
-
Priority bumped 1->0: Parodi told in writing (Rendiciones API doc v2.6) this field is being fixed - now load-bearing for an external commitment, not internal hygiene.
-
0
-
DEV complete: DEFAULT CURRENT_DATE removed and importer bootstrap no longer creates it. PROD still retains the default and requires a fresh explicit PROD GO for the audited migration; no code work remains. Prospective source-date semantics belong to MOVILBA-146.
-
1
-
p0 is reserved for items blocked on an Elazar decision; this deferred PROD-GO follow-up is p1.
-
unassigned
-
MEDIDO 2026-09-23, y CORRIGE lo que yo mismo dije hace una hora en el blackboard de coder03 y en MOVILBA-537: el DEFAULT de PROD no es la causa principal, y DEV NO tiene este ticket medio arreglado. Censo de escritores de public.vehiculos.fecha_ultima_actualizacion, las dos bases, SELECT only: solo hay dos funciones que la nombran, fn_archive_vehiculos() (copia al archivo, no decide valor) y rutap.reconciliar_snapshot(integer,boolean). El codigo de la app no la escribe: parque-movil.ts:205 solo la EXPONE en la descarga de Parque Movil / API externa. Y reconciliar_snapshot, linea 484 del cuerpo instalado, EN LAS DOS BASES, dice literal: fecha_ultima_actualizacion = current_date O sea: el camino de ACTUALIZACION estampa la fecha de la corrida en DEV igual que en PROD. Lo que MOVILBA-145 borro en DEV fue el DEFAULT, que solo actua en el INSERT de un vehiculo nuevo. El escritor dominante quedo intacto en los dos lados. Consecuencias: 1. Sacar el default en PROD sigue siendo correcto y reversible, pero NO cierra 145: cierra el camino de alta y deja el de actualizacion, que es el que toca a todos los vehiculos existentes en cada import. 2. DEV no es el estado bueno al que PROD tiene que converger en este campo. Los dos estan mal, de la misma forma, en el camino que importa. 3. La mitad que escribe la fecha CORRECTA del libro no existe en ninguna de las dos bases. Eso es lo que 146 tiene que definir, y por eso el header de la migracion dice a proposito que no hace backfill. No cambia la recomendacion de aplicar la pata PROD del default (ACT NOW, DDL pre-live, reversible en una sentencia), pero si cambia el reporte: despues de aplicarla 145 sigue ABIERTO, y el trabajo que queda esta en reconciliar_snapshot, no en el esquema.
-
El escritor dominante ya tiene ticket propio: MOVILBA-540 (rutap.reconciliar_snapshot estampa current_date sobre los 2413 en cada import, identico en DEV y PROD). 145 queda como la pata del DEFAULT; 540 es el resto; 146 sigue siendo la definicion del valor correcto. Ninguno de los tres esta aplicado.
-
MOVILBA-539 abierto: el DEFAULT que esta migracion bajo en DEV es el escritor MENOR. El dominante es rutap.reconciliar_snapshot linea 484, identico en las dos bases y sin tocar, asi que 145 quedo a medias de los DOS lados y DEV no es el estado bueno al que PROD converge. Si algun dia se baja el default de PROD, el reporte NO puede decir '145 hecho' - ver el texto exacto exigido en el evento decision de MOVILBA-537.
-
CORRECCION al alcance que yo mismo escribi aca y en MOVILBA-540: reconciliar_snapshot NO estampa fecha_ultima_actualizacion en todo vehiculo en cada import. Su UPDATE (lineas 473-493 del cuerpo instalado) lleva WHERE ... IS DISTINCT FROM sobre la tupla COMPLETA de columnas proyectadas, o sea solo alcanza los vehiculos cuya fila proyectada cambio de verdad. Cite el SET y no el WHERE. El detalle completo, con la tercera opcion de decision que esto abre y los 99 vehiculos de PROD cuya edicion de app es posterior al sello, esta en las notas de MOVILBA-540.
-
STARTED MOVILBA-145 (pata read-through) 2026-09-23 11:28:38 -03 por coder03-mba-l-cc. GO: Elazar, CLI, 11:27 ART, relayado por db03-mba-l-cc: "go" sobre la opcion (b) READ-THROUGH. La definicion del valor correcto la dio el mismo Elazar, verbatim: "could not fecha_ultima_actualizacion show the date in estado actual" - o sea el campo NO se arregla escribiendo mejor, se deja de escribir y se PROYECTA desde el periodo vigente. Las dos implementaciones sobre la mesa eran (a) WRITE IT (que reconciliar_snapshot estampe la fecha del expediente en vez de current_date) y (b) READ-THROUGH (que el campo salga del historial vigente y la columna se retire); coder03 y db03 recomendaron (b) por separado y (b) es lo aprobado. Reparto: db03 escribe y aplica el artefacto DDL de reemplazo de v_vehiculos_detalle en DEV y PROD (coder03 es SELECT only), mas su pata de reconciliador linea 484, columna, idx_vehiculos_fecha_actualizacion, default de PROD, y la columna de vehiculos_archive + cuerpo de fn_archive_vehiculos(). coder03 carga la pata de aplicacion. El DROP de la columna va DESPUES de que la vista + API esten vivas en PROD. Superficies censadas hoy (grep, repo completo): public.vehiculos.fecha_ultima_actualizacion (columna), vehiculos_archive (schema.ts:1706), v_vehiculos_detalle (schema.ts:3049, proyecta v.fecha_ultima_actualizacion), src/repositories/parque-movil.ts:63 y :205 (API externa Parque Movil, el consumidor de Parodi), src/types/vehiculos.ts:159, src/lib/openapi/components.ts:626 y :646 (campo PUBLICADO y en la lista de requeridos). Riesgo abierto que coder03 le pasa a db03 antes del DDL: v_vehiculos_detalle hoy resuelve el periodo vigente por v_vehiculos_hist_ultimo -> rutap.vehiculo_historial_normalizado, NO por rutap.v_vehiculo_historial_actual, que es la que usa parque-movil.ts:135-155. Si el artefacto agrega la segunda al lado de la primera, la vista queda con DOS resolutores de periodo vigente y la ficha puede mostrar una fecha distinta que la API para el mismo vehiculo. Ademas v_vehiculo_historial_actual devuelve una fila por (vehiculo, dominio), asi que un replate tiene dos filas rank-1 y hay que reproducir el desempate canonico de parque-movil.ts:149-153. Que db03 NOMBRE cual resolutor usa; coder03 se alinea al que nombre.
-
PATA VISTA DE (b) READ-THROUGH APLICADA, DEV y PROD (orden de Elazar: 'go' sobre (b)). Artefacto docs/migrations/2026-09-23-movilba-145b-detalle-fecha-desde-estado-actual-DEV-Y-PROD.sql md5 d63466962676011fcc523c7fcc17001e, SIN COMMITEAR (lo commitea coder03). v_vehiculos_detalle.fecha_ultima_actualizacion ahora proyecta fecha_alta del periodo vigente via rutap.v_vehiculo_historial_actual con el desempate canonico de parque-movil.ts:143-149, LIMIT 1. POST medido: PROD 2413->2413 filas, 0 NULL, 10->10 vistas dependientes, owner movilba_owner y ACL sin cambio; AI563JN 2026-09-18 -> 2026-09-11 (= Vigencia desde de la ficha). Gate verificado ABORTANDO con una proyeccion equivocada antes de correr el real. HALLAZGO: v_vehiculos_detalle NO es la misma vista en DEV y PROD (DEV: overlay periodo_veh + sin vdc.observaciones ni sube/openpass; PROD al reves) - se aplico un cuerpo por base, cada uno con UN solo cambio; converger es otra decision. movilba_owner no tiene CREATE en schema public, asi que un CREATE OR REPLACE VIEW en PROD corre como superuser (REPLACE conserva el owner). PENDIENTE: pata 2 (columna, indice, DEFAULT, linea 484 del reconciliador, columna y fn_archive_vehiculos de vehiculos_archive con 1662 filas) va DESPUES del deploy prod de coder03.
-
MOVILBA-145 (b) READ-THROUGH: pata de codigo APLICADA Y VIVA EN PROD 2026-09-23 11:37 ART. SHAs: dev 96b1314e (v5.6.20) y 7de6aeeb (v5.6.21); PROD main f5557874, v5.6.21. El arbol desplegado /srv/movilba-web tiene la linea nueva (parque-movil.ts:222). app.movilba.com/api/health responde ok. Que cambio, por superficie: - src/repositories/parque-movil.ts: la lateral del periodo vigente ahora tambien selecciona current_h.fecha_alta, y el SELECT de la pagina publica vh.fecha_alta::text AS fecha_ultima_actualizacion en vez de v.fecha_ultima_actualizacion. fecha_alta es date en la vista, asi que ::text ya da el format 'date' del contrato; no hizo falta ::date::text. - v_vehiculos_detalle: reemplazada por db03 en DEV y PROD (artefacto docs/migrations/2026-09-23-movilba-145b-detalle-fecha-desde-estado-actual-DEV-Y-PROD.sql, md5 d63466962676011fcc523c7fcc17001e, committeado por coder03 sin modificar; 261 lineas, solo CREATE OR REPLACE, escaneado por DROP/DELETE/TRUNCATE/ALTER/GRANT/CASCADE antes de committear, ninguno). Proyecta cur_fa.fecha_alta desde una LATERAL sobre rutap.v_vehiculo_historial_actual con el MISMO desempate que parque-movil.ts, no por v_vehiculos_hist_ultimo: hist_ultimo sale del mismo origen pero sin desempate y puede abanicar en un replate. - src/lib/openapi/components.ts:626: el campo conserva nombre, tipo y su lugar en la lista de requeridos (renombrarlo rompe a SOTAMIT); se le agrega description para que el consumidor deje de leer el nombre como "cuando se toco la fila". - Los dos comentarios de MOVILBA-98 que explicaban por que se habia sacado el rotulo "Ultima Actualizacion" de la ficha y del formulario quedan anotados: el diagnostico sigue siendo cierto SOBRE LA COLUMNA, y por eso la columna se retira. Volver a poner el rotulo ahora que el campo tiene fuente real es una DECISION de Elazar, no un arreglo obvio - NO se repuso. - El espejo drizzle/schema.ts se regenero con ./mba-introspect.sh y se verifico token a token: el unico cambio es la proyeccion mas la lateral cur_fa. El diff crudo dice 57/57 lineas porque el bloque vVehiculosDetalle se reubico en el archivo; la lista de columnas es identica. MEDICION EN PROD, tomada ANTES del apply, que es la delta visible para Parodi: 2413 vehiculos vivos, 0 sin fila en rutap.v_vehiculo_historial_actual, 0 que queden null, y 2407 de 2413 CAMBIAN DE VALOR. El rango se mueve de [2025-12-08, 2026-09-19] a [2025-06-19, 2026-09-18]. Que el piso viejo sea tres meses posterior al nuevo es el agrupamiento por fecha de lote visto como numero: la columna no podia reportar nada anterior al import que la escribio. DECLARACION DE COBERTURA. Ejercitado: la forma nueva de la consulta corrida directo contra DEV (3 filas, fechas reales, sin error de SQL) y la medicion fila por fila en PROD de arriba. NO ejercitado: la ruta HTTP de punta a punta. POST /api/v1/parque/vehiculos/search devolvio 401 sin autenticar - eso es la compuerta funcionando, no un defecto, y no se busco una credencial para rodearla. O sea el SQL esta probado y la capa de serializacion NO. Falta para cerrar 145: db03 baja la columna, el indice idx_vehiculos_fecha_actualizacion, el DEFAULT de PROD, la linea 484 de reconciliar_snapshot y la plomeria de vehiculos_archive + fn_archive_vehiculos(). Recien ahi se cierra.
-
leg 2 applied DEV+PROD: column, index, both writers retired; gate green (view 2413, archive 1662 kept, 4 triggers, owner/ACL unchanged). Artifact docs/migrations/2026-09-23-movilba-145b2-*.sql md5 326158d1734b8de66dbf1c2b9b72922d, untracked for coder03. Archive column drop pending Elazar.
-
AUDITADO Y APROBADO por audit-mba-l-ca el 2026-09-23 11:53 ART sobre 509761e2 (dev) y PROD main 721b9eb8. Hallazgo de audit, NO bloqueante pero real, aceptado y corregido en el mismo turno: la prosa que yo habia escrito decia que el campo es 'la fecha del tramite mas reciente que lo afecta', y eso es FALSO para un tercio del parque. Re-medido por coder03 en PROD antes de patchear, reproduce exacto lo de audit: de 2413 vehiculos vivos, 807 tienen el periodo SELECCIONADO cerrado con fecha_baja POSTERIOR al valor publicado, 1599 tienen periodo abierto, 0 tienen fecha_alta nula. La redaccion correcta es 'fecha de alta (inicio) del periodo seleccionado como Estado Actual'. Corregido en tres superficies: src/lib/openapi/components.ts (la description ahora excluye explicitamente las DOS lecturas equivocadas, marca de edicion y ultimo tramite), los dos comentarios de MOVILBA-98 (con el reparto 807/1599/0 escrito adentro para que nadie vuelva a derivar la frase mala), y docs/reference/parque-movil-api/data-contract.md seccion 2.3.1 NUEVA, que registra el cambio de semantica como historial de contrato: que era antes, que es ahora, como NO describirlo, la salvedad del periodo cerrado y la delta medida. Audit tenia razon en que una description de OpenAPI no es historial de contrato. DECISION DE ELAZAR, CLI, 2026-09-23, y cierra dos cosas que estaban abiertas: NO se bumpea la version del spec (queda en 2.2.0) y NO se le informa nada a German Osses Macchia (SOTAMIT). Su razon: German solo MUESTRA el campo a titulo informativo, no lo usa en logica de negocio. Yo habia ofrecido 2.3.0 y lo rechazo. El 2.2.0 sin bumpear es una decision, no un descuido - no volver a levantarlo. Verificacion de que el contrato sigue en pie POR VALOR, corrida despues de esa decision justamente porque nadie va a ser avisado de re-chequear nada. PROD, conjunto vivo COMPLETO: 2413 filas de la forma de consulta de la API, 0 null, 0 que fallen ^[0-9]{4}-[0-9]{2}-[0-9]{2}$, y 0 que discrepen contra v_vehiculos_detalle joineando por id - las dos superficies coinciden en TODAS las filas vivas. Ademas se grepearon las referencias que quedan a la columna caida en src/: cinco, todas del lado de la SALIDA (tipo de fila, el alias en parque-movil.ts:222, el tipo de TS que alimenta la vista detalle, la lista de required, un comentario). Ninguna sentencia SQL lee public.vehiculos.fecha_ultima_actualizacion. Unico item de cobertura declarado abierto, y audit lo confirma como declarado y no como defecto nuevo: la serializacion HTTP no esta ejercitada. POST /api/v1/parque/vehiculos/search da 401 sin autenticar, que es la compuerta funcionando, y no se busco credencial para rodearla. FALTA para cerrar 145: la columna vehiculos_archive.fecha_ultima_actualizacion sigue en pie, nullable, con sus 1662 fechas y filas nuevas en NULL. Su baja pende de la palabra de Elazar (db03). El hueco de enforcement del desempate quedo en MOVILBA-542.
-
audit-mba-l-ca 12:23 ART: both legs pass (md5s reproduce, live DEV+PROD checked; leg 2 committed 1d8b968d). DEV v_vehiculos_detalle fanout (2444 rows/2423 ids) pre-exists, is DEV data, waived per scope rule (data measured in PROD only; PROD 2413/2413). Open: vehiculos_archive.fecha_ultima_actualizacion drop/keep, Elazar.
-
db03-mba-l-cc
-
db04-mba-l-ca
-
researcher-mba-l-cc / solo
-
2026-10-08T12:50:08-03:00 researcher-mba-l-cc re-measurement. The named bug is already fixed and live in PROD since 2026-09-23 (SHA f5557874, v5.6.21): option (b) READ-THROUGH shipped - the API and v_vehiculos_detalle now project the field from the current period's fecha_alta via rutap.v_vehiculo_historial_actual with the canonical tie-break, not from the vehiculos.fecha_ultima_actualizacion column. Confirmed by grep today: zero live readers of that column in src/ - the five remaining hits are a type comment, a SQL comment explaining the migration, two code-comment notes in page.tsx/editar colectivo page.tsx documenting that the published field no longer reads it, and the openapi components.ts field/required-list entry which is the renamed OUTPUT, not the column. No statement anywhere selects public.vehiculos.fecha_ultima_actualizacion. What remains open per the ticket's own last note (2026-09-23 14:40, wi-cli-venus): db03 still needs to drop the column itself, idx_vehiculos_fecha_actualizacion, PROD's DEFAULT, reconciliar_snapshot's line 484, and the vehiculos_archive/fn_archive_vehiculos() plumbing (1662 archived rows) - all pending Elazar's word per the audit's 2026-09-23 verified note. The column still holds the old batch-date values (confirmed by the same 2026-09-23 measurement: 2407/2413 rows changed value once the read-through went live, range moved from [2025-12-08, 2026-09-19] batch-clustered to [2025-06-19, 2026-09-18] real), it is just dead data now with zero readers. Nothing to re-measure on the batch-vs-real-date question - that was answered and fixed. The only open item is the column-drop GO, already correctly tracked as pending Elazar in the 2026-09-23 verified note. Status unchanged.
-
coder03 2026-10-08 13:02 ART: closed on researcher's trace. The importer no longer stamps the batch date - the read-through from v_vehiculo_historial_actual has been live in PROD since 2026-09-23 and there are zero live readers of vehiculos.fecha_ultima_actualizacion left in src/. What remains is the column/index/default drop plus reconciliar_snapshot:484 and the archive plumbing, which is tracked separately and waits on Elazar's word.
bug
7w ago by wi-cli-venus
1w ago
2026-10-08 15:51