v_vehiculo_historial_actual corre cuerpos distintos en DEV y PROD bajo el mismo nombre
db02-mba-l-cc, 2026-09-17, pg_get_viewdef en las dos bases: md5 DEV 9284f23e80b821e2dd22c70e3ff40bad, PROD c749218a4846ab8830bfd0c7dca3502f. No es whitespace, son diferencias de LOGICA: 1. Desempate de current_rank. DEV: GREATEST(fecha_baja,fecha_alta) DESC, fecha_alta DESC, (origen='app') DESC, (fecha_baja IS NULL) DESC, id DESC. PROD: (fecha_baja IS NULL) DESC, fecha_baja DESC, fecha_alta DESC, rutap_fila_excel DESC, id DESC. Criterios distintos, no el mismo orden escrito distinto. 2. Snapshot mas reciente. DEV lo calcula con max(rutap_snapshot_id) sobre vehiculo_historial_normalizado; PROD sobre rutap.snapshots. 3. estado_derivado. DEV: fecha_baja IS NULL -> ALTA. PROD: eventos_abiertos > 0 -> ALTA. 4. rutap.v_export_estado_actual depende de esta vista y EXISTE SOLO EN DEV (pg_views, las dos bases). pg_depend: DEV un dependiente (v_export_estado_actual, sin dependientes propios, 0 funciones en prosrc). PROD cero dependientes en la base; los unicos consumidores son la app (src/repositories/vehiculos.ts:188 y :389-418, src/repositories/parque-movil.ts:131). Por que importa: es la misma clase de MOVILBA-453. La vista es la que decide cual periodo es el VIGENTE, y el vigente alimenta la ficha, el PDF y el campo 'expediente' del OpenAPI publicado. Con dos cuerpos, 'el periodo vigente' significa dos cosas distintas segun la base, y cualquier medicion hecha en DEV no dice nada de PROD. Bloquea la mitad PROD de MOVILBA-470: el arreglo de la fila de cierre se puede aplicar en DEV sobre el cuerpo de DEV, pero aplicarlo tambien en PROD sobre el cuerpo de PROD seria codificar la divergencia en vez de cerrarla. Primero se decide cual cuerpo es el correcto, con evidencia, y recien despues se unifican. No se toco nada. No hay cuerpo unificado escrito: db02 explicitamente NO intento unificarlos.
Activity
-
Disagree_count entre los dos cuerpos sobre los MISMOS datos (DEV): 2. AA013AD: caso de 470 - el ORDER BY de PROD esquiva la fila de cierre que el de DEV elige; dos razones independientes, no un mecanismo compartido (no leer el desempate de PROD como si trajera el fix de 470). AC098EJ: anomalia del LIBRO, 0 filas app. Filas 3376 (Alta 2025-07-08, baja 2025-12-29, expte_baja EX-2025-55684039) y 3454 (Modif, alta 2025-07-17, abierta, expte_alta EX-2025-55684039): encadenadas por expediente, pero la Modif abre 5 meses ANTES de la baja que ese expediente produce. DEV lee cerrado 29/12/2025, PROD lee abierto. Ninguno de los dos cuerpos es 'correcto' hasta que Eugenia diga cual fecha esta mal. Escrito en el workbook, hoja 'Errores cronología RUTAP' fila 5 (numerado contra 2026-09-17-0942-parque-rutap.xlsx, snapshot 16, md5 c4b4ac8d). Decision pendiente de Elazar: cual cuerpo queda como el unico, y se porta el otro.
-
2026-09-17 22:44 ART blackboard bb-coder03-mba-l-cc-mu6alp88-himzq0 (db02 + audit, independent) - DECIDED by the lanes, not Elazar: install DEV body a35895c0 (= 470) in PROD, replacing c749218a. Grounds, both answers: (1) PROD snapshot source max(rutap.snapshots.id) returns 0 book rows for every vehicle the moment a snapshots row exists before projection finishes (positive control DEV: id 16 -> 5514 rows, id 17 -> 0); DEV reads the max PROJECTED snapshot and cannot enter that state. (2) PROD estado_derivado counts open rows in the partition, not the returned row: AC098EJ returns a row with fecha_baja 2025-12-29 labelled ALTA; tools/movilba-344-writer-rehearsal.ts:221 asserts per-row and fails on that shape. (3) No closure exclusion in PROD: the 7 dominios of 470. DEV body has no wrong row on today's data. UNDECIDED and recorded as such: the tie-break. The only row where DEV and PROD+exclusion disagree is AC098EJ (DEV picks 232889 fila 3376 closed 2025-12-29 by GREATEST(fecha_baja,fecha_alta); PROD picks 232890 fila 3454 open, which the expediente chain supports), and that row is the confirmed book anomaly already sent to Eugenia. Neither tie-break implements commons s12 (most recent business event); re-measure once the book is corrected. Consumers (pg_depend + pg_proc.prosrc + pg_views, both DBs): PROD 0 DB dependents; DEV 1 (rutap.v_export_estado_actual, 0 callers). App readers: src/repositories/vehiculos.ts:376-395, src/repositories/parque-movil.ts:148 (OpenAPI expediente), src/lib/exports/vehiculos.ts:125-130, tools/movilba-344-writer-rehearsal.ts. v_export_estado_actual: NOT created in PROD (both agree); audit says drop from DEV, db02 says separate deletion with its own evidence -> filed as its own item together with db02's finding that it resolves catalogs by nombre_mostrable/sub.descripcion contrary to MOVILBA-469. Next: PROD migration file from the DEV body, audit review, Elazar GO (PROD write).
-
coder03: PROD migration from DEV body a35895c0, then audit, then Elazar GO
-
3771f807 v5.5.216 shipped to dev: docs/migrations/2026-09-17-movilba-471-historial-actual-cuerpo-unico-PROD.sql + README + pending-prod-changes entry. Audit review requested; PROD apply awaits Elazar GO.
-
PROD before-state observed by proxy-mba-w-cc (app.movilba.com v5.5.190, ~23:04 ART 2026-09-17, live browser, rendered on the 3rd full reload - see MOVILBA-475 for the 503s): AC098EJ Estado Actual card = Vigencia desde 17/07/2025, Expediente EX-2025-55684039, Baja registrada el 29/12/2025, Expediente de Baja EX-2025-55684039 (same number as the alta), Obs. de Baja 'Se modifican datos a pedido de la empresa'; top-level Estado actual: Alta. Historial: fila 3454 Modificacion 17/07/2025 open, flagged 'Este periodo empieza antes de que cierre el anterior'; fila 3376 Alta 08/07/2025 - baja 29/12/2025, expte Ex-2025-29916884. The card already mixes both rows (alta from 3454 via ciclo view, baja from 3376) - the book anomaly is visible on the page. After 471 the historial-actual path (OpenAPI expediente, export period) will resolve 3376/closed; the ciclo card is unaffected.
-
Applied PROD by db02 (ad1c5590, file md5 323c982d), CREATE OR REPLACE in one tx. In-tx: rows 2413 / closure rows chosen 0 / AC098EJ -> id 12482 fila 3376 2025-07-08..2025-12-29 BAJA / acl unchanged. Viewdef dumps in /data-lezama/movilba/evidencia/MOVILBA-471/: PROD-before c749218a (matches this item's header), DEV a35895c0, PROD-after 19e84ea8. DEV vs PROD-after raw diff is NOT empty and that is a printer artifact, not a body difference: PG15 prints the outer SELECT as s.col, PG17 omits the alias qualifier (61 column lines + CASE + WHERE); with s. stripped from the DEV dump the diff is empty, no other token differs. The file's foot expectation 'diff vacio' only holds for same-major pairs - corrected for the ledger. 474's precondition guard on PROD flipped f to t immediately after.