v_vehiculo_historial publica borrado_en como fecha de fin de periodo y ordena por creado_en: una columna de auditoria decide lo que el usuario lee
Medido por coder02-mba-l-cc el 2026-09-03 con SELECT contra PROD. Dos defectos en la misma vista, los dos INDEPENDIENTES de la decision de visibilidad pre-handoff que espera a Elazar en MOVILBA-170. Esta no decide QUE ve el usuario: arregla COMO se calcula lo que ya ve. DEFECTO 1 - periodo_hasta = COALESCE(vh.fecha_baja, vh.borrado_en::date). Promueve una columna de auditoria a afirmacion de negocio, contra la regla dura. Y no queda en la base: se RENDERIZA - src/app/vehiculos/[id]/page.tsx y src/components/ExpedienteForm.tsx imprimen 'hasta <fecha>' cuando viene y 'sin cierre (periodo actual)' cuando es NULL. ALCANCE: la vista devuelve 4225 filas; periodo_hasta sale de una fecha_baja REAL en 2616 y del fallback de borrado_en en 9. Las 9 son exactamente el conjunto de MOVILBA-171 (4 pares de doble import + AG732SW): AD919PL 8933/8934, AE922FX 8247/9028, AE971FE 8222/8972, AE971FF 8244/8965, AG732SW 4608. Cada par comparte fecha_alta y difiere en borrado_en, asi que el fallback le daba dos cierres distintos a dos filas que son el MISMO periodo importado dos veces. DEFECTO 2 - ORDER BY COALESCE(vh.fecha_alta, vh.creado_en::date) DESC, vh.creado_en DESC. commons seccion 12 (v5.4.102) prohibe ordenar por creado_en, y aca aparece dos veces. El fallback hoy no se ejerce (0 filas visibles con fecha_alta NULL) pero el DESEMPATE si: 18 filas empatan en (vehiculo_id, fecha_alta) y en 12 de ellas creado_en y id dan ordenes DISTINTOS. La ficha muestra newest-first, o sea esas 12 se presentan en un orden que depende de cuando corrio el import. Reemplazo: fecha_alta DESC NULLS LAST, id DESC. CUAL SOBREVIVE AL REBUILD: el defecto 2. Con la directiva de truncate-and-rebuild de Elazar, borrado_en queda vacio y el defecto 1 se vuelve codigo muerto - pero la expresion sigue siendo incorrecta y el desempate por creado_en sigue vivo, porque el rebuild cambia FILAS, no la definicion de la vista. coder-mba-l-ca confirmo el 09-03 que 125/203/204 NO reescriben ni retiran esta vista: 203 la esquiva y el destino aprobado agrega v_vehiculo_historial_actual y migra consumidores en el cutover. O sea hay que arreglar la vista vieja ahora, y el cutover la retira, no le preserva la semantica. Su instruccion explicita: no arrastrar COALESCE(fecha_baja, borrado_en) a NINGUNA de las dos vistas. SQL escrito, con dos gates y control positivo: docs/migrations/2026-09-03-movilba-224-v-vehiculo-historial-columna-de-auditoria-DEV-PROD.sql. No escribe un solo dato. Despues de aplicar hay que correr introspect.sh - drizzle/schema.ts trae la definicion vieja embebida. NO CUBRE: no filtra vehiculo_historial.borrado_en (eso es MOVILBA-170 y depende de Elazar) ni toca el JOIN a opciones (un camino de LECTURA resuelve la etiqueta sin filtrar, regla de Elazar del 09-03).
Activity
-
TRES CORRECCIONES DE db02-mba-l-cc, medidas, que abaratan mucho este item. 1. EL PATRON DE PROCEDENCIA YA EXISTE EN ESTE ESQUEMA. Las tres tablas de vehiculos no tienen NINGUNA columna de actor (cero matches de actor|usuario|user|persona|editad|modific), pero validadoras_historial ya trae actor_id, actor_nombre y actor_email, y validadoras, validadoras_historial y validadoras_historial_ubicaciones ya llevan triggers *_append_only y *_no_truncate. O sea este item NO es 'inventar un mecanismo de procedencia': es 'aplicarle a las tablas de vehiculos el patron que las tablas de validadoras ya shipean'. Eso tambien abarata MOVILBA-182. 2. CORRECCION A MI CONTEO, conclusion sin cambios. No son 4224 de import y 1 de la app. creado_por en PROD: import-rutap-2026-08-14-prod 2274, system_import 1599, snapshot5 171, import-movilba-19 164, movilba-104-prod 7, import-movilba-18 4, import-movilba-24 3, 'Elazar (GO 2026-08-25 via db02-mba-l-ca)' 2, '20394678369' 1. O sea 4222 de import/migracion, 2 escritas por un agente bajo GO, 1 de la app. creado_por sigue sin discriminar - la conclusion del item no se mueve, pero el numero que se cite tiene que ser este. 3. YA TENEMOS 233 FILAS DEL PROBLEMA, HOY, EN DEV. rendiciones.deudas_dominios tiene 233 filas con FK a vehiculos y NO sale del libro. No es un riesgo futuro: es el primer dataset concreto que un import de reemplazo destruye. Se salva porque esa tabla ya trae una columna dominio al lado del vehiculo_id. LA REGLA GENERAL QUE SALE DE AHI, y que va escrita en el importer en vez de re-deducirse por tabla: ATRAVESANDO UN REBUILD, LA CLAVE ESTABLE ES dominio; EL id SUBROGADO NO LO ES. Un import de reemplazo reasigna vehiculos.id, asi que cualquier cosa que guarde un vehiculo_id guarda un puntero que el rebuild invalida EN SILENCIO - sin error de FK, porque el id se reusa para otro vehiculo. Todo lo que no venga del libro se aparca por dominio antes del delete y se re-resuelve despues.
-
CORRECCION DE NUMERO: la nota anterior de este item (el patron de procedencia de validadoras, el desglose de creado_por y las 233 filas de rendiciones.deudas_dominios) NO es de este ticket. Va en MOVILBA-224, el bloqueante de procedencia, donde ya esta repuesta. Este item es solo el bug de la vista v_vehiculo_historial. Lo detecto db03-mba-l-ca leyendo el ticket, no yo. El SQL quedo en docs/migrations/2026-09-03-movilba-225-v-vehiculo-historial-columna-de-auditoria-DEV-PROD.sql (se shipeo primero con el nombre 224 y se renumero).
-
MEDIDO EL 2026-09-05 07:53. La sobrecarga de esta vista tiene ahora un caso REAL Y CONTABLE, no hipotetico. db02-mba-l-cc leyo la definicion con pg_get_viewdef: v_vehiculo_historial NO filtra vh.borrado_en. El unico predicado de borrado_en es 'JOIN vehiculos v ON vh.vehiculo_id = v.id AND v.borrado_en IS NULL', o sea sobre VEHICULOS, no sobre la tabla de historial. La vista ademas expone vh.borrado_en como columna y calcula 'periodo_hasta = COALESCE(vh.fecha_baja, vh.borrado_en::date)'. CONSECUENCIA MEDIDA: tras aplicar MOVILBA-255 (107 filas con borrado_en = now() el 07:41), las 107 tienen fecha_baja NULL, asi que su periodo_hasta pasa a ser 2026-09-05. db02 conto exactamente 107 filas de la vista con periodo_hasta = 2026-09-05 y son exactamente esas: ninguna otra fila de la tabla trae esa fecha. O sea que periodo_hasta CONFUNDE 'el libro cerro este periodo' con 'nosotros retiramos esta fila', y hoy hay 107 casos que lo demuestran. NO HAY CONSUMIDOR HOY, verificado por coder02 con git grep sobre origin/dev: 'periodo_hasta'/'periodoHasta' aparece UNICAMENTE en la declaracion de drizzle/schema.ts:2035-2036. Ningun codigo de aplicacion la selecciona. Por eso esto NO es un incidente y no se revirtio 255. LO QUE HAY QUE ARREGLAR ACA: periodo_hasta tiene que dejar de coalescear borrado_en. Un fin de periodo es un dato del libro; borrado_en es una marca nuestra. Es la sobrecarga de MOVILBA-83 escrita adentro de una definicion de vista, y mientras siga ahi cualquier lector nuevo hereda el defecto sin saberlo. LO QUE NO SE MIDIO: v_vehiculos_hist_ultimo SI filtra h.borrado_en IS NULL sobre la tabla de historial, asi que ahi las 107 quedan OCULTAS en vez de mal fechadas; nadie midio todavia si a algun vehiculo le cambio la fila 'ultimo' por eso. Tampoco se abrio ninguna ficha.
-
SEGUNDA MEDICION, db02-mba-l-cc 2026-09-05 07:55, sobre el OTRO lector. Cierra el riesgo de 255 y abre un defecto propio de esta vista. v_vehiculos_hist_ultimo: vehiculos cuya fila 'ultimo' cambia excluyendo las 107 retiradas por MOVILBA-255 contra incluyendolas = CERO, sobre 2414 vehiculos comparados. Vehiculos que desaparecen de la vista = CERO. CONTROL POSITIVO, porque un cero de un instrumento que no puede reportar distinto de cero no vale nada: el mismo arnes, corrido contra un estado donde se sacan 20 filas que HOY ganan, reporta exactamente 20 cambiadas. El arnes detecta el cambio. POR QUE ES CERO, y esto es lo que hay que conservar: la vista ordena por (existe sucesor), fecha_alta DESC NULLS LAST, id DESC. En los 107 pares la fila abierta y la cerrada tienen la MISMA fecha_alta en 107 de 107, y la abierta tiene el id MENOR en 107 de 107. O sea que la fila retirada ya perdia el desempate por id contra su propia pareja ANTES de 255. Nunca fue la ultimo, y retirarla no podia mover nada. DEFECTO PROPIO DE ESTA VISTA, independiente de 255 y sin medir: la subconsulta EXISTS que decide 'sucesor' hace SELECT FROM vehiculo_historial SIN predicado de borrado_en. El WHERE h.borrado_en IS NULL de afuera NO entra a la subconsulta. Asi que filas soft-deleteadas - las 107 incluidas - siguen VOTANDO en el orden de las filas vivas. Es exactamente la trampa 'un filtro borrado_en en la tabla externa no cubre la subconsulta', viva en una vista que SI se lee. Aca no mordio porque el resultado lo decidio el desempate por id. SIN MEDIR: si esa ceguera de la subconsulta cambia algun orden HOY para filas que no tienen nada que ver con 255. Necesita su propio denominador y es parte del arreglo de este item.
-
coder03-mba-l-cc / coder
-
researcher-mba-l-cc 2026-09-24 03:57 - migration header changed to MOVILBA-225 (commit 0295bece); backlog, blocker is MOVILBA-224 per bwi description
-
coder03assistant-mba-l-ca | 2026-09-24 04:04:18 ART DEV movilba_dev / PROD movilba installed public.v_vehiculo_historial still defines periodo_hasta=COALESCE(h.fecha_baja,h.borrado_en::date). Rows: 5582 DEV, 5528 PROD; current fallback-input count 0/0, so no present symptom but defective definition remains. Migration SQL exists in dev/main; DB apply and introspection remain open.
-
db03-mba-l-cc
-
Re-authored the fix against the CURRENT installed view - the 2026-09-03 migration (docs/migrations/2026-09-03-movilba-225-...) targets FROM vehiculo_historial vh, a table MOVILBA-227's reload retired; public.v_vehiculo_historial now sources rutap.v_vehiculo_historial_normalizado_fuente_actual, so that old file cannot apply as written. New migration: docs/migrations/2026-09-28-movilba-225-v-vehiculo-historial-periodo-hasta-DEV-Y-PROD.sql. Defect 1 (periodo_hasta = COALESCE(fecha_baja, borrado_en::date)) still present verbatim in the installed view - fixed to periodo_hasta = fecha_baja, no fallback. Defect 2 (ORDER BY creado_en) is MOOT: 227's rebuild dropped ordering from this view entirely, confirmed via pg_get_viewdef, no ORDER BY clause exists. Consumer-level ordering is fixed separately (MOVILBA-232, this session, same queue). Rehearsed clean under ROLLBACK: gate (periodo_hasta IS DISTINCT FROM fecha_baja) = 0 rows, 5545 rows/30 cols unchanged. No live case exercises the old fallback today (borrado_en 0/5545 PROD, 0/5587 DEV, same finding as 232) - correctness fix, no visible symptom to demo, disclosed not fabricated. Ready for audit PASS.
-
audit pass: md5 guard verified vs live PROD (matches). Re-authored against post-227 view, periodo_hasta=fecha_baja (borrado_en fallback dropped). Defect-2 mootness confirmed (227 dropped ordering). In-migration gate asserts periodo_hasta=fecha_baja on every row. Row/col sanity.
payload
{"scope":"md5 guard verified vs live PROD (matches). Re-authored against post-227 view, periodo_hasta=fecha_baja (borrado_en fallback dropped). Defect-2 mootness confirmed (227 dropped ordering). In-migration gate asserts periodo_hasta=fecha_baja on every row. Row/col sanity.","outcome":"pass","evidence":"file full read; own psql: PROD viewdef md5 matches pin","reportRef":null} -
Applied to PROD, audit PASSed. v_vehiculo_historial.periodo_hasta now equals fecha_baja always, no borrado_en fallback. 5545 rows/30 cols unchanged, gate 0 distinct. Not yet ported to DEV.
-
db04-mba-l-ca
-
db03-mba-l-cc / db
-
Defecto 2 (ORDER BY creado_en) ya era MOOT desde el rebuild 227 (vista sin ORDER BY, orden lo pone el consumidor - MOVILBA-232 lo arreglo ahi). Defecto 1 (periodo_hasta via borrado_en) estaba aplicado solo en PROD (09-28, audit PASS); portado a DEV hoy (2026-10-08, db03): md5 pre-cambio de DEV coincidia exacto con el pineado en el archivo (7d5556d7...), asi que el mismo migration file aplico sin reescritura. Rehearsal limpio, apply limpio, gate 0 filas con periodo_hasta distinto de fecha_baja, md5 post-cambio en DEV = a9b33b9c... (identico a PROD). docs/migrations/README.md actualizado. Cierra, dos bases convergidas.
-
audit pass: periodo_hasta gate SELECT, both DBs
payload
{"scope":"periodo_hasta gate SELECT, both DBs","outcome":"pass","evidence":"count(periodo_hasta IS DISTINCT FROM fecha_baja)=0 in both PROD and DEV - matches claim","reportRef":null} -
audit pass: docs/migrations/README.md hunk, DEV-apply wording
payload
{"scope":"docs/migrations/README.md hunk, DEV-apply wording","outcome":"pass","evidence":"already independently confirmed this session: periodo_hasta gate 0 mismatches both DBs","reportRef":null}