v_vehiculos_hist_ultimo elige bien HOY solo porque borrado_en separa vivas de muertas - hay que arreglarla ANTES de MOVILBA-42, no despues
Done normal
dmdb02-mba-l-ca
Detectado por db02-mba-l-cc al medir MOVILBA-69. Las filas de vehiculo_historial forman una CADENA: el expediente_baja de una fila es el expediente de la siguiente. La vista ordena por fecha_expediente DESC, creado_en DESC; cuando dos filas comparten fecha (AH850GK tiene 3 filas del mismo dia) el desempate cae en creado_en y elige un eslabon ANTES de la cola. Regla correcta: 'la fila cuyo expediente_baja no es el expediente de ninguna hermana' - devuelve 131/131 y matchea vdc 131/131, contra 128/131 de la vista. MOVILBA-65 NO esta afectado (medido, no asumido): solo lee vehiculo_id/entidad_id/linea_id y esos son identicos entre las filas de un mismo vehiculo, 0 de 28 difieren. Muerde a cualquiera que lea expediente o fecha a traves de la vista.
Activity
-
GO de Elazar 2026-08-20.
-
RE-ALCANCE (db02 midio, coder-mba-l-cc acepta). EL BUG NO PUEDE DISPARAR HOY EN PROD: MOVILBA-69 cerro el camino. Prod 05:29: 1736 vehiculos vivos, 1736 con EXACTAMENTE una fila viva de historial, CERO con ninguna (la rama de fallback), cero con mas de una; regla DISTINCT ON contra regla de cadena, 1736 comparados, 1736 coinciden, 0 difieren. MECANISMO: hist_ultimo ordena por (borrado_en IS NOT NULL) PRIMERO, asi que siempre cae en la fila viva cuando existe una. El desempate fecha_expediente/creado_en - el defecto real - solo es alcanzable cuando un vehiculo tiene CERO filas vivas y la vista tiene que caer a las borradas. Antes de 69 eso eran 131 vehiculos y erraba en 3; despues de 69 son cero y no erra en ninguno. EL BUG ESTA DORMIDO, NO ARREGLADO. DECISIONES: (1) NO se pliega dentro del paso 3 de MOVILBA-76 - el valor entero del paso 3 es que es un rename puro demostrablemente seguro (87 vistas, 848 columnas de salida, cero cambios, cero roturas); meterle un cambio de COMPORTAMIENTO adentro cambia esa propiedad por un deploy menos, y si 73 se portara mal habria que despegarlo de un rename para revertirlo. (2) NO se prioriza como arreglo de ordenamiento: cuando vuelva a ser alcanzable va a ser porque un vehiculo perdio su unica fila viva, que ES el defecto original de 69 volviendo. Arreglar el ORDER BY trata el sintoma; el arreglo durable es impedir vehiculos con cero filas vivas - constraint o gate de ingesta - y eso pertenece a la linea 42/46 de coder02, no a una definicion de vista. (3) 73 SE CONVIERTE EN MONITOR, no en fix: un chequeo que reporte cualquier vehiculo con cero filas vivas de historial, o sea la condicion que reactiva el bug, para enterarnos por una alarma y no porque Eugenia vea un campo vacio. Es la pieza que faltaba cuando 131 vehiculos estuvieron meses en ese estado. Si algun dia se endurece el ordenamiento igual, va DESPUES del paso 3, en su propio archivo, escrito contra expte_alta/expte_baja.
-
db02-mba-l-cc / db
-
PRE-REQUISITO DESCUBIERTO 2026-08-20 06:09 (db02). v_monitor_historial_anomalias calcula filas_vivas como count(*) FILTER (WHERE h.borrado_en IS NULL). Eso es borrado_en usado como liveness, y bajo la sobrecarga descubierta en MOVILBA-83 no significa lo que dice el comentario de la vista. HOY el veredicto es correcto por casualidad: con borrado_por NULL en las 2309 y cero soft-deletes genuinos, 'borrado_en IS NULL' y 'no borrado' coinciden. SE ROMPE en cuanto se retire la sobrecarga: despues del backfill de 83, las 2309 pasan a ser filas vivas y la clase MULTIPLES_VIVAS dispara sobre 1293 vehiculos de golpe. REGLA DE ORDEN: el monitor de 73 NO va a prod antes del backfill de 83, o se reescribe primero contra fecha_baja. Hoy esta aplicado SOLO en dev, baseline 0/0/0, y no se esta pidiendo GO para prod.
-
parent=MOVILBA-12
-
db02 06:16: ordenar por fecha_expediente sola NO arregla los 3 vehiculos, rompe mas (7 errores vs 2). Lo que los arreglo fue la regla de cadena, ya shipeada en 69. El arreglo de 73 NO es un cambio de desempate: queda como monitor sobre la condicion que reactiva el fallback. Y 73 NO bloquea contra 12 -- el fallback es inalcanzable mientras todo vehiculo vivo tenga exactamente una fila viva. Sigue en pie el prerequisito ya registrado: el monitor usa borrado_en como liveness y no va a prod antes del backfill de 83, o se reescribe antes contra fecha_baja.
-
STILL OPEN pero INALCANZABLE, medido en prod por db02-mba-l-cc 2026-08-21 08:11. v_vehiculos_hist_ultimo existe y devuelve 1738 filas; de los 1737 vehiculos con historial vivo, CERO tienen mas de una fila viva - el maximo es 1 - porque uq_vehiculo_historial_activo lo impide. El desempate donde vive el bug nunca se entra. Asi que esto no es un bug que se pueda reproducir hoy: es un item con forma de monitor, y va detras de MOVILBA-42, que es el refactor que introduciria multiples filas vivas y lo volveria alcanzable. Su prerequisito declarado sigue en pie: v_monitor_historial_anomalias NO existe en prod (es dev-only, verificado) y hay que reescribirla contra fecha_baja antes de que viaje.
-
v_vehiculos_hist_ultimo elige bien HOY solo porque borrado_en separa vivas de muertas - hay que arreglarla ANTES de MOVILBA-42, no despues
-
Deja de ser item de monitor detras de 42: es PREREQUISITO de 42. Medido por db02-mba-l-cc en prod 10:01.
-
MEDIDO EN SERIO, prod 10:01 ART por db02-mba-l-cc, y el veredicto es CHANGED: el defecto no se manifiesta hoy, pero la RAZON que el ticket daba para que fuera inofensivo es AHORA FALSA, y eso es lo accionable. LA VISTA, leida y no supuesta: SELECT DISTINCT ON (vehiculo_id) vehiculo_id, entidad_id, linea_id FROM vehiculo_historial ORDER BY vehiculo_id, (borrado_en IS NOT NULL), fecha_alta DESC NULLS LAST, creado_en DESC. Ya trae NULLS LAST y no tiene join a vehiculos. ELIGE MAL? NO, en ningun lado. Comparada la eleccion de la vista contra la regla de cadena del propio ticket (la fila cuyo expte_baja no es el expte_alta de ninguna hermana) sobre los 1738 vehiculos con historial: 0 eligen otra fila, 0 difieren en entidad_id, 0 difieren en linea_id. Los 3 de 131 que reportaba el ticket ya no estan. POR QUE ESTA VERDE: la PRIMERA clave del ORDER BY es (borrado_en IS NOT NULL), asi que las filas vivas ordenan antes que las muertas, y 1737 de 1738 vehiculos tienen exactamente una fila viva - el desempate por fecha/creado_en nunca se alcanza. AH850GK, el ejemplo del propio ticket, lo prueba: sus ids 10638 (viva) y 10639 (muerta) EMPATAN en fecha_alta 2026-03-02 y lo resuelve la clausula de liveness antes de que el desempate entre en juego. Correcta por accidente de liveness, no por el orden que el ticket critica. LA PREMISA QUE MURIO: el ticket dice que MOVILBA-65 no se ve afectado porque entidad_id/linea_id son identicos entre las filas de un vehiculo - '0 de 28 difieren', medido sobre 28. Ya no es cierto: 124 de 1738 vehiculos varian entidad_id entre sus filas de historial y 121 varian linea_id. O sea que una eleccion equivocada AHORA cambiaria lo que la vista PROYECTA, cosa que no podia pasar cuando se escribio el ticket. De los 6 vehiculos que todavia tienen empate real de fecha_alta dentro del mismo grupo de liveness (AD919PL, AD956UK, AE922FX, AE971FE, AE971FF, AG358KX), 3 varian entidad y 3 varian linea: la poblacion del empate y la del dano ya se cruzan. EL ACOPLE QUE NADIE HABIA ESCRITO, y es por lo que esto importa mas alla de 73: la correccion de la vista descansa ENTERAMENTE en que borrado_en discrimine viva de muerta. MOVILBA-83 existe para que borrado_en deje de llevar la Fecha Baja de RUTAP, y MOVILBA-42 dropea uq_vehiculo_historial_activo, que es lo que mantiene una sola fila viva por vehiculo. Si aterriza cualquiera de los dos, esta vista deja de estar salvada por su primera clave de orden y cae al desempate del que habla el ticket, sobre una poblacion donde 124 vehiculos pueden proyectarse mal. ARREGLO, barato: cambiar el desempate fecha/creado_en por la regla de cadena, que hoy reproduce la vista exactamente. Asi sigue siendo correcta cuando la liveness deje de rescatarla. Es CORV y necesita GO. Nota de metodo: coder02-mba-l-cc probo empates exactos entre filas VIVAS, dio 0, y reporto explicitamente 'no lo verifique' en vez de publicar ese cero - la pregunta era empates dentro de un GRUPO de liveness, que son los 6 de arriba. El cero era correcto y contestaba otra pregunta.
-
AGRAVADO por db-mba-l-cc, prod 10:01, reproduciendo por su cuenta y encontrando algo que db02 no midio: LOS 6 EMPATES SON EMPATES COMPLETOS, creado_en incluido. Vehiculos que empatan en (liveness, fecha_alta, creado_en) = 6, o sea TODOS los 6. Asi que el ORDER BY no elige ganador entre ellos: DISTINCT ON se queda con la fila que el plan le entregue primero. No es un desempate debil, es un desempate AUSENTE - y el '0 difieren de la regla de cadena' de db02 es UNA ejecucion de una eleccion que no tiene respuesta definida. Un VACUUM, un cambio de plan o un indice nuevo la mueven en silencio. La afirmacion correcta es 'coincide hoy', no 'elige bien'. Y 3 DE LOS 6 PROYECTARIAN DISTINTO: AE922FX, AE971FE y AE971FF tienen en sus filas empatadas 2 entidad_id distintos Y 2 linea_id distintos cada uno. La indeterminacion llega a las columnas proyectadas, no solo a la identidad de la fila. POR QUE PROD SIGUE VERDE, medido y no argumentado: los 6 empates son entre filas MUERTAS (borrado_en NOT NULL) y cada uno de esos 6 vehiculos tiene exactamente 1 fila viva, que la primera clave de orden pone adelante de todo. Vehiculos cuyo ganador de DISTINCT ON este el mismo dentro de un empate completo: CERO. O sea que el defecto es real, esta presente en los datos, y hoy es inalcanzable - blindado enteramente por la clave de liveness. LO QUE AFILA LA SECUENCIA: 1295 vehiculos tienen mas de una fila de historial. En cuanto la liveness deje de discriminar - 42 dropeando uq_vehiculo_historial_activo, u 83 cambiando lo que significa borrado_en - los 1295 caen a un desempate que es DEMOSTRABLEMENTE incapaz de resolver al menos 6, sobre una poblacion donde 124 pueden proyectarse mal. El escudo aguanta hoy; el escudo es exactamente lo que 42 y 83 sacan. REQUISITO QUE SE AGREGA AL ARREGLO: el orden tiene que quedar TOTAL, no solo mejor. La regla de cadena es correcta, pero lo que aterrice necesita una clave final deterministica - h.id es la obvia - para que ningun empate futuro vuelva a ser arbitrario. Un desempate que puede empatar es la misma forma que un gate que no puede dudar de su propia clave.
-
TESTIGO COMPARTIDO CON MOVILBA-42: AD919PL (ids de historial 8933 y 8934) es a la vez uno de los 6 vehiculos con empate TOTAL de este ticket y una de las 4 colisiones de la clave de evento candidata de 42 - dos filas identicas del mismo cargador en la misma corrida. Los dos tickets miran la misma fila desde angulos distintos: 73 dice que el ORDER BY no puede elegir entre ellas, 42 dice que no deberian ser dos filas. Medido por coder02 en PROD 2026-08-21.
-
CORRECCION: el solapamiento con MOVILBA-42 es de CINCO vehiculos, no uno. Mi nota anterior decia 'comparten testigo' en singular y estaba construida sobre una lista incompleta (mi conteo de colisiones era 4; el bueno es 8, medido por db-mba-l-cc). Interseccion real entre los 6 vehiculos con empate TOTAL de este ticket y los que colisionan bajo la clave de evento de 42: AD919PL, AD956UK, AE922FX, AE971FE, AE971FF. El unico de los 6 que NO esta en 42 es AG358KX, y db verifico POR QUE en vez de dejarlo: sus dos filas del 2026-03-09 difieren en fecha_baja y tramite_id (id 7839 cierra el mismo dia como ALTA/317, id 7842 corre hasta 2026-04-21 como MODIF/318), asi que empatan bajo la clave de ORDEN de 73 pero son eventos distintos bajo la clave de IDENTIDAD de 42. Enunciado fuerte: la clave de evento propuesta por 42 colisiona en CINCO de los SEIS vehiculos cuyo orden 73 no puede resolver. Un fix que lee historia por identidad de evento y un fix que elige la fila mas reciente estan los dos rotos sobre las mismas cinco filas, por razones DISTINTAS. Son dos preguntas sobre una poblacion solapada, no un mismo defecto contado dos veces.
-
creado_en no puede desempatar: la clave terminal de v_vehiculos_hist_ultimo es una CONSTANTE, no una clave debil. Medido en PROD 2026-08-21 10:36 por coder02-mba-l-cc, coincide celda por celda con db-mba-l-cc y db02-mba-l-cc. DEFINICION HOY (prod): ORDER BY vehiculo_id, (borrado_en IS NOT NULL), fecha_alta DESC NULLS LAST, creado_en DESC. SEMANTICA DE creado_en: 2441 de 4052 filas (60%) guardan la propia fecha_alta a las 00:00:00 exactas, no un timestamp de ingesta. 2441/2441 son medianoche exacta. Split limpio por loader: import-rutap-2026-08-14-prod 2274/2274 backdated, import-movilba-19 164/164, import-movilba-24 3/3; system_import 0/1599, movilba-104-prod 0/7, import-movilba-18 0/4, 20394678369 0/1. Ese ultimo creado_por es un id numerico pelado: creado_por NO es vocabulario controlado. POR QUE NO DISPARA, por dos mecanismos independientes: (a) en las filas backdated creado_en = fecha_alta POR CONSTRUCCION, o sea es funcionalmente dependiente de la clave anterior; (b) en las no-backdated creado_en es constante POR LOTE (system_import: 5 valores distintos en 1599 filas; los otros tres loaders: 1 valor cada uno). Medido: de los 6 grupos que llegan a la clave terminal, 6/6 tienen un solo creado_en distinto. Discrimina cero, en toda la tabla, hoy. Por eso los 6 casos son empates COMPLETOS y no empates parciales: el desempate es una repeticion de lo ya empatado. CONSECUENCIA PARA EL FIX: reemplazar creado_en por h.id es un cambio de CORRECTITUD, no un parche de determinismo. Criterio nuevo, ademas del de audit: la clave de reemplazo tiene que ser INDEPENDIENTE de las claves anteriores. h.id lo es; creado_en demostrablemente no. LO QUE NO ES CIERTO, medido para que nadie lo re-derive: - El riesgo de direccion invertida (creado_en corre al reves del orden de insercion: las filas rutap tienen creado_en MENOR e id MAYOR que las system_import) tiene CERO instancias hoy. Los 6 grupos empatados son todos de un solo loader (import-rutap-2026-08-14-prod) y las 12 filas estan soft-deleted. Los pares de dos loaders nunca empatan aca porque se parten en (borrado_en IS NOT NULL), que es la PRIMERA clave. Latente, a un insert de loader mixto de volverse real. - Los 6 empates son ademas inalcanzables: cada uno de los 6 vehiculos (3766 AD919PL, 4093 AE922FX, 4109 AE971FE, 4110 AE971FF, 4453 AG358KX, 5189 AD956UK) tiene exactamente UNA fila viva, que gana la primera clave, asi que el DISTINCT ON nunca baja al empate. - creado_en IS NULL = 0 filas y fecha_alta IS NULL = 0 filas, asi que el footgun de DESC (NULLS FIRST: un NULL ordenaria primero y GANARIA) no dispara hoy. A un insert nullable de distancia. CRITERIO DE AUDIT PRE-VERIFICADO: corri las dos vistas lado a lado en prod. creado_en DESC = 1738 filas, id DESC = 1738 filas, EXCEPT en ambas direcciones = 0. El cambio de clave terminal no mueve ni una fila del output de hoy. Memoria: reference_creado_en_is_a_business_date_for_most_of_the_table. ABIERTO Y SIN DUEnO (lo levanto db-mba-l-cc): si algun analisis pasado uso creado_en para establecer que fila se escribio primero, es sospechoso sobre esas 2441 filas.
-
parent=MOVILBA-125
-
db02-mba-l-ca / db
-
Preparing a dependency-safe view migration: preserve the current output today, use the historical chain tail as the semantic ordering rule, and use history id only as an independent final tie-breaker.
-
DEV applied and verified on 2026-08-26: 1,813 rows, zero output differences, one row per vehicle. The final chain comparison now normalizes expediente text. PROD remains pending Elazar’s separate fresh GO.
-
Applied and verified in both DEV and PROD on 2026-08-26. PROD: 1,740 selected rows, zero difference from prior view output, one row per vehicle; post-commit 1,740 rows / 1,740 distinct vehicles / zero duplicates. Chain-tail matching normalizes expediente text; id is the deterministic final tie-breaker.
bug
2026-08-20 by wi-cli-venus
7w ago
2026-08-26 10:37