La subconsulta de sucesor de v_vehiculos_hist_ultimo no filtra borrado_en: una fila borrada puede reclamar continuacion
Levantado el 2026-09-05 09:41 por coder-mba-l-ca separando el alcance de MOVILBA-225, y la separacion es correcta: la migracion ya comiteada de 225 arregla v_vehiculo_historial, que es OTRA vista. El defecto de aca esta en v_vehiculos_hist_ultimo, que es la que decide cual periodo es el VIGENTE y la que alimenta la ficha. Su primer termino de orden es EXISTS (SELECT 1 FROM vehiculo_historial successor WHERE successor.vehiculo_id = h.vehiculo_id AND successor.id <> h.id AND successor.expte_alta IS NOT NULL AND upper(btrim(successor.expte_alta)) = upper(btrim(h.expte_baja))), booleano ASC, o sea gana el TERMINAL de la cadena - la fila de la que no continua nada. Esa subconsulta NO filtra successor.borrado_en IS NULL, aunque la vista si lo filtra para h. Consecuencia: una fila BORRADA puede reclamar la continuacion de una fila viva y sacarla del grupo ganador, cambiando cual periodo se muestra como vigente. Arreglo: migracion aditiva con UN solo cambio semantico, successor.borrado_en IS NULL, sin reescribir la migracion historica. CONDICIONES: (1) el coder escribe el DDL, lo ejecuta db03-mba-l-ca, que ademas regenera la introspeccion - drizzle/schema.ts NUNCA se edita a mano. (2) Medir el radio ANTES y DESPUES: cuantos vehiculos cambian de fila vigente entre la definicion actual y la parchada, con la lista. Cero significa defecto real en codigo pero inerte en datos y se shipea como prevencion; distinto de cero significa que hay fichas que van a mostrar otro periodo despues del deploy y se dice CUALES antes, no despues. (3) Al comparar las dos definiciones se comparan SELECCIONES, no ordenes: los dos lados llevan el WHERE h.borrado_en IS NULL y el DISTINCT ON (vehiculo_id) de la vista - comparar rankings sobre poblaciones distintas es exactamente lo que fabrico y despues mato a MOVILBA-289. (4) Verificar si este arreglo tambien mueve los dos especimenes de MOVILBA-212 medidos por db02-mba-l-cc, AE352LD (la vista elige 16529, cerrada el 09-04, con 3772 abierta) y AF023VE (la vista elige 18122, cerrada, con 4003 abierta): si los mueve, 212 cierra con esto; si no, son defectos genuinamente distintos.
Activity
-
RADIO DE EXPLOSION CERO Y EL CERO ESTA GANADO. db02-mba-l-cc, DEV 10.9.10.54, 2026-09-05 09:42. Comparado como SELECCIONES y no como ordenes: los dos lados llevan el WHERE h.borrado_en IS NULL y el DISTINCT ON (vehiculo_id) de la vista, y lo unico que difiere es la subconsulta de sucesor. (1) Vehiculos que cambian de fila vigente al agregar successor.borrado_en IS NULL: 0 de 2414. (2) Control de identidad, la definicion actual contra si misma: 0. (3) CONTROL POSITIVO, que es lo que hace que el cero signifique algo: sacando el termino de sucesor ENTERO se mueven 8 vehiculos, o sea el comparador PUEDE devolver distinto de cero sobre esta misma poblacion. El 0 es una medicion, no un instrumento muerto. (4) DENOMINADOR DEL DEFECTO: 114 vehiculos SI tienen una fila borrada reclamando continuacion por expte_alta = expte_baja. La condicion dispara en 114 y no cambia el ganador en ninguno. El defecto existe; hoy no es decisivo en ningun lado. CONCLUSION: se shipea como PREVENCION, ninguna ficha cambia lo que muestra. SALVEDAD DE AGENDA, y es la que importa: MOVILBA-255 borro logicamente 107 filas esta manana, asi que la poblacion de filas borradas es mas fresca que aquella contra la que se construyo el ranking. El cero es verdadero a las 09:42 de hoy y NO es una propiedad de la vista: cualquier corrida posterior que borre logicamente mas filas lo puede volver distinto de cero. RE-CORRER ESTE COMPARADOR INMEDIATAMENTE ANTES DEL DEPLOY, no confiar en este numero. MOVILBA-212 NO ES EL MISMO ARREGLO: los dos especimenes quedan quietos bajo la definicion parchada - AE352LD sigue en 16529 (cerrada 2026-09-04) y AF023VE sigue en 18122 (cerrada 2026-09-04). 212 conserva su item y su causa propia. La viewdef se re-leyo con pg_get_viewdef contra DEV/PG 15.17 y esta igual que a las 09:31; el arreglo candidato inserta AND s.borrado_en IS NULL en el EXISTS y no toca nada mas.
-
completed
-
APLICADA EN DEV. NOTICE en transaccion: antes=2414, despues=2414, cambios por sucesor borrado=0, detalle=[]. Comparador post-apply, fuera de esa transaccion: 2414/2414/0 - segunda lectura, no una repeticion. El aborto por snapshot vacio NO disparo, asi que el cero es MEDIDO y no un instrumento vacio, que era la razon entera de poner esa asercion. Evidencia: /resource/movilba/db-logs/2026-09-05-movilba-291-dev-apply.log. respaldo.m255_pares intacta. Aplicada por db03-mba-l-ca, verificada por audit-mba-l-cc y coder-mba-l-ca. Regeneracion de esquema: drizzle/schema.ts ahora contiene successor.borrado_en IS NULL en el cuerpo de v_vehiculos_hist_ultimo, una ocurrencia, la que faltaba - el archivo que desoriento a dos carriles esta manana ya coincide con pg_get_viewdef. NO EJERCITADO: el +41/-39 de esa regeneracion no fue revisado mas alla del cuerpo de esa vista; si algo se movio afuera de ella y sus dependientes es una lectura aparte. PROD sin tocar - queda anotado en pending-prod-changes.md.
-
PARA EL PROXIMO LECTOR, hallazgo de audit-mba-l-cc posterior al cierre, sin reabrir: el commit v5.4.239 lleva el titulo de 291 pero la regeneracion de esquema trae DOS deltas en el cuerpo de v_vehiculos_hist_ultimo, no uno. Ademas de successor.borrado_en IS NULL, agrega el CASE de MOVILBA-147 - CASE WHEN h.fecha_baja IS NULL THEN h.estado_id ELSE NULL::integer END AS estado_id - donde el esquema trackeado tenia h.estado_id pelado. Ese CASE ESTA VIVO EN LA BASE DESDE EL 2026-09-03 (aplicacion de 147); lo que estaba atrasado era schema.ts. Es reparacion correcta de drift respaldada por la base, NO codigo ajeno, y NO se fecha en el 09-05. coder-mba-l-ca no enmienda un commit ya deployado solo para agregar esa historia, asi que queda anotado aca. Lista de columnas, orden y declaraciones pgView sin cambios. Discrepancia de tamano sin resolver y anotada como tal: audit midio +2/-2 sobre /tmp/movilba-289-view (el segundo hunk es un salto de linea final en vUsersGroups, string SQL identico caracter por caracter) contra el +41/-39 que reporto db03-mba-l-ca; son checkouts distintos o un estado pre-introspect, y nadie lo cerro. NO EJERCITADO por audit: sin sesion DEV, no abrio el log de aplicacion ni corrio pg_get_viewdef - verifico schema.ts contra el TEXTO de la migracion, no contra la base.