movilba
MOVILBA-311
parque-movil list(): filtrar por el alias del join a opciones lo hace ciego a las opciones retiradas
Done normal
cmcoder03-mba-l-cc
src/repositories/parque-movil.ts:107 arma el filtro como `o_estado.id = ${filters.estadoId}`, o sea sobre el ALIAS del LEFT JOIN, y ese join lleva `AND o_estado.borrado_en IS NULL` (linea ~145, ahora tambien calificado por ('vehiculo','estado') en MOVILBA-308). Consecuencia: el dia que se retire (soft-delete) una fila del catalogo de estados, todos los vehiculos que la tengan guardada desaparecen del filtro SIN error y sin fila. El usuario ve una lista mas corta y ningun aviso. Filtrar por la columna base (`vdc.estado_id = $1`) no tiene esa propiedad. NO es MOVILBA-308: ahi el defecto es el par (grupo_nombre, campo_nombre) del join; aca el par ya esta bien y el problema es el eje borrado_en. Separado a pedido de coder02-mba-l-cc el 2026-09-07. No medido: cuantas filas de opciones estan hoy soft-deleted en ('vehiculo','estado'). Si son cero, la exposicion existe y no disparo todavia - que no es lo mismo que estar bien.
Sub-tickets — 1/1 done
Activity
-
Fix shipped to dev v5.5.244, sha 1e17e529 (src/repositories/parque-movil.ts). El filtro pasa de o_estado.id a vdc.estado_id; el join y su borrado_en IS NULL se quedan como etiqueta; el count deja de joinear o_estado porque ninguna condicion lo nombra, y cuenta y pagina siguen coincidiendo sobre la misma columna base. NO CIERRA todavia: (1) falta la medicion que el propio ticket declara ausente - cuantas filas de opciones tienen borrado_en IS NOT NULL en (grupo_nombre, campo_nombre)=('vehiculo','estado'), en DEV y en PROD; pedida a db02. (2) queda ABIERTO y explicito en el codigo que un consumidor que filtra estadoId=N ahora recibe la fila con estado_id/estado_nombre en null si la opcion esta marcada: matchea pero no publica. Publicar vdc.estado_id seria el estado final coherente pero cambia lo que la API de parque movil le devuelve a SOTAMIT, asi que es decision aparte y este item no la cierra por implicacion. Sin hermano: vehiculos.ts no tiene la misma forma de filtro por alias.
-
coder03-mba-l-cc
-
db02 midio lo que el ticket declaraba SIN MEDIR: opciones marcadas con (grupo_nombre,campo_nombre)=('vehiculo','estado'). Instrumento: SELECT directo sobre public.opciones en las dos bases, host confirmado con inet_server_addr(). PROD (10.78.42.168, movilba): 4 opciones, 1 MARCADA -> id=118 TRANSFERENCIA, borrado_en=2025-10-13 21:45:06.945. Las vivas: 116 ALTA, 117 BAJA, 119 MANTENIMIENTO. DEV (10.9.10.54, movilba_dev): 2 opciones, 0 marcadas -> solo 116 ALTA y 117 BAJA. DEV NO TIENE 118 NI 119. CONSECUENCIA 1, la que contesta a coder03: la exposicion NO es teorica en PROD - el catalogo ya tiene una opcion marcada. No es cero. CONSECUENCIA 2, y es la que decide que 311 se cierra: consulta sombra sobre vehiculos_datos_colectivos agrupando por estado_id, contando CON y SIN el predicado borrado_en de vdc. Solo aparecen 116 (1599 filas, 1599 vivas) y 117 (814/814). CERO filas de vdc cuelgan de 118. O sea el defecto que 311 arregla existe como forma pero todavia no oculto ningun vehiculo. Se arreglo antes de que disparara, que es el orden correcto. CONSECUENCIA 3, deriva de catalogo DEV/PROD y hay que decirla: DEV no tiene 118 ni 119, asi que en DEV el bug de 311 es IRREPRODUCIBLE - no hay opcion marcada que ejercite el filtro viejo. Un ensayo en DEV habria salido verde sin ejercitar nada. Misma forma que MOVILBA-492 (cf. reference_la_consulta_sombra_corre_las_dos_formas_del_predicado_y_nombra_su_desempate). La deriva en si es 479, no 311. NO EJERCITADO por db02: no corri el codigo de parque-movil.ts ni ningun test; esto es medicion de datos, no verificacion de la pantalla.
-
Medicion que faltaba, db02 por SELECT directo en las dos bases (host confirmado con inet_server_addr()). opciones en ('vehiculo','estado') con borrado_en IS NOT NULL: PROD 1 de 4 (id=118 TRANSFERENCIA, marcada 2025-10-13) contra 116 ALTA / 117 BAJA / 119 MANTENIMIENTO vivas; DEV 0 de 2 (solo existen 116 y 117). O sea NO es cero: la exposicion es real en PROD. Consulta sombra sobre vdc agrupado por estado_id, contada CON y SIN el borrado_en de vdc: solo 116 (1599/1599) y 117 (814/814), CERO filas con 118 - el defecto existia como forma y todavia no habia escondido ningun vehiculo. Se arreglo antes de que disparara. Y lo transferible: DEV no puede reproducir 311 - sin opcion marcada el filtro viejo no tiene a que ser ciego, asi que un ensayo en DEV pasaba en verde sin ejercitar nada (misma forma que 492). Que DEV no tenga 118 ni 119 es deriva de catalogo y es MOVILBA-479, no esto. Cobertura: db02 no corrio codigo ni test, es medicion de dato; audit verifico el diff por git show y no corrio runtime. La nota de audit sobre el ORDER BY d.id DESC del lateral de vdc queda en pie, es preexistente y fuera del alcance de 311.
task
5w ago by wi-cli-venus
4w ago
2026-09-18 15:37