movilba
MOVILBA-556
v_vehiculos_export.ultima_modificacion publica creado_en, no la fecha del tramite
Blocked normal
cmcoder03assistant-mba-l-ca
⛔ Awaiting Elazar's A/B semantic decision: A keep the existing field/header and publish the canonical current-period trámite date, or B retain creado_en and rename the output field/header to describe record-creation time. No implementation until decided.
Found by audit-mba-l-ca on 2026-09-23 while reviewing MOVILBA-145. The XLSX/CSV export publishes ultima_modificacion as (SELECT max(h.creado_en) FROM v_vehiculo_historial h WHERE h.vehiculo_id = v.id), verified in the view body. creado_en is the row-insertion timestamp, so the column reports when our database wrote a row, not when the vehicle's procedure happened. This contradicts the standing history-model rule that the current row is the most recent BUSINESS event and never creado_en, and it means a pure re-import can move a vehicle's published last-modified date without any real change. Note v_vehiculos_export_resumen has the same shape via GREATEST(v.creado_en, COALESCE(lh.creado_en, v.creado_en)). Separate from MOVILBA-145: that ticket fixed fecha_ultima_actualizacion, which this export does not publish at all. Decide whether the export should publish the current period's fecha_alta with the canonical tie-break (same resolver as parque-movil.ts:157) or drop the column; the external XLSX/CSV consumer sees it, so the change is visible outside.
Activity
-
coder03assistant-mba-l-ca
-
researcher 2026-10-08 13:22 ART: still a real, unfixed decision - checked the installed v_vehiculos_export directly, ultima_modificacion still computes max(h.creado_en), exactly the defect as filed, unchanged since 2026-09-23. Same shape survives in v_vehiculos_export_resumen's GREATEST(v.creado_en, COALESCE(lh.creado_en, v.creado_en)). The choice is live: publish the current period's fecha_alta with the canonical tie-break (parque-movil.ts:157's resolver) or drop the column. External XLSX/CSV consumer sees it either way.
-
researcher 2026-10-08 13:24 ART: consumer census done, as asked. EXACTLY ONE real consumer of v_vehiculos_export.ultima_modificacion in the whole repo: src/lib/exports/vehiculos.ts's COLUMNS array maps it to XLSX/CSV header 'Modificación más reciente' - this is the fleet export, built by db.select().from(vVehiculosExport) (whole-view select) and streamed by /api/v1/exports/vehiculos/route.ts via that same shared builder (route.ts's own comment confirms it defers to vehiculos.ts). No other src file (analisis-importacion.ts, parque-movil-live.ts, liquidacion.ts) that references v_vehiculos_export selects or reads this column - they use other fields of the same view. v_vehiculos_export_resumen's equivalent (GREATEST(...)) has ZERO repo consumers at all - no file references the resumen view or symbol. docs/reference/parque-movil-api/ has zero mentions of ultima_modificacion, ultimaModificacion, or the resumen view - this field is not part of the published /api/v1 contract. So the one real reader is a human looking at an XLSX/CSV column labeled 'most recent modification' - changing its semantics from creado_en to the canonical tramite date is a meaning correction a human reader would want, not a breaking change to any programmatic consumer.
-
coder03-mba-l-cc 19:2xZ - promoted for the coder03assistant lane after 449 closed and the 408 AST landed.
-
Starting the four-surface consumer census before any semantic change.
-
Coder source census, read-only, before any behavior change. Four candidate surfaces checked: (1) v_vehiculos_export is selected wholesale by src/lib/exports/vehiculos.ts:117; its ultimaModificacion column at :67 is emitted by the shared XLSX and CSV builders at :195/:218, served by /api/v1/exports/vehiculos/route.ts:66. This is an actual external output consumer. (2) Internal /api/export?resource=vehiculos also reads via fetchVehiculosExportRows, but src/lib/exports/parque-movil-live.ts maps to RutapHistoricalRow without ultimaModificacion, so this route does not publish the field. (3) v_vehiculos_api_public exposes ultima_modificacion in drizzle/schema.ts:3102-3114; scripts/sync-to-api.ts:94 selects it, but mapToPayload at :112-126 omits it from the outgoing SyncPayload. The systemd movilba-sync.service invokes this script; this is an internal read, not a published payload field. (4) v_vehiculos_export_resumen equivalent was reported by prior census and has no source/API-doc reader in the tracked repo; no generated Drizzle symbol found. docs/reference/parque-movil-api has zero field/key/label mentions. Thus repository evidence supports one actual published output path with XLSX and CSV formats; the other candidates are either dropped before output or have no repo consumer. No code/DB changes made. Decision still needed per item: correct the output to the canonical current-period trámite date, or remove the column; no HTTP download or live PROD/DEV view-definition query was exercised in this pass.
-
Refined the four-surface census as route+format pairs in the shared source tree: (1) /api/v1/exports/vehiculos?format=xlsx emits ultimaModificacion via src/lib/exports/vehiculos.ts:67,117,195 and route.ts:66; (2) the same endpoint with format=csv emits it at :218; these two are real external outputs. (3) /api/export?entity=vehiculos&format=xlsx and (4) the same route with format=csv use RUTAP_LIBRO_COLUMNS and fetchParqueMovilExportRows -> mapLiveFleetToParqueExportRows, which drops ultimaModificacion; neither emits the field. Therefore the claim of four emitted outputs is not supported by repo code: only the two v1 formats publish it. Additional candidates: v_vehiculos_api_public exposes ultima_modificacion and scripts/sync-to-api.ts selects it, but mapToPayload omits it; v_vehiculos_export_resumen has no tracked source/API-doc reader or generated Drizzle declaration. docs/reference/parque-movil-api contains no mention. This inventory is source-level only; no live HTTP response or PROD/DEV view definition was queried. No code/DB change. The existing item still requires choosing between correcting the v1 field to the canonical current-period trámite date (recommended: retain the header and correct its value) or removing it.
-
Decision for Elazar — one externally published route, two formats; no code/DDL changed. Source census: /api/v1/exports/vehiculos emits the column in XLSX and CSV via the shared v_vehiculos_export builder. /api/export XLSX/CSV drops the field. scripts/sync-to-api.ts selects v_vehiculos_api_public.ultima_modificacion but mapToPayload drops it. v_vehiculos_export_resumen has no tracked reader, and docs/reference/parque-movil-api has no field/key mention. Unknown external consumer; blast radius is one route and two formats. Choose: A) keep the header/key and source its value from the canonical current-period trámite date; or B) keep the current creado_en value and rename the output field/header to accurately identify it as MovilBA record-creation time. Recommendation from coder: A corrects the mislabeled value while preserving the existing column.
-
Awaiting Elazar's A/B semantic decision: A keep the existing field/header and publish the canonical current-period trámite date, or B retain creado_en and rename the output field/header to describe record-creation time. No implementation until decided.
bug
3w ago by wi-cli-venus
1w ago