movilba
MOVILBA-331
· child of MOVILBA-315 La app LEE entidad/linea de public.vehiculo_historial y las ESCRIBE en rutap.vehiculo_historial_normalizado Done
El alta escribe estado_id y la edicion no, asi que todo periodo abierto por una edicion nace sin estado
Done high
cmcoder-mba-l-ca
El camino de edicion de colectivo abre el periodo sucesor en rutap.vehiculo_historial_normalizado SIN arrastrar estado_id. Medido en FB444EP (id 6723) el 2026-09-07: la fila de alta 80587 lleva estado_id 116, y las dos filas de edicion 80588 y 80589 lo llevan NULL. Escrito en repositories/vehiculos.ts:1081-1094, el insert del evento de edicion no incluye estadoId entre sus values, mientras que el insert del alta en :688-705 si lo hace. Hoy es INVISIBLE porque toda la lectura de estado pasa por public.vehiculo_historial, que ni siquiera tiene estas filas. Se vuelve visible en el instante exacto en que MOVILBA-315 repunte la lectura hacia la capa normalizada: en ese momento todo vehiculo que haya sido editado alguna vez pasa a resolver estado NULL, y el arreglo de 315 se leeria como una regresion nueva. Por eso es bloqueante de la verificacion de 315 aunque no lo sea de su codigo: el control de 315 tiene que mirar estado ademas de entidad/linea, o el arreglo se declara bueno mientras rompe una tercera columna. Decidir tambien cual es el valor correcto a arrastrar - el estado del periodo que se cierra, o el que corresponde al tramite de modificacion - antes de escribirlo. No inventar: sale de lo que el periodo anterior tenia.
Activity
-
parent=MOVILBA-315
-
2026-09-07 16:56 - SHIPEADO EN v5.5.48 (59a48dce) Y CORREGIDO EN v5.5.51 (028a00d0). Sin ejercitar: nadie edito un vehiculo por el formulario. ARREGLO: currentHistorial en repositories/vehiculos.ts no SELECCIONABA estadoId, asi que el arrastre no estaba 'roto' - el valor no estaba DISPONIBLE para arrastrar. Se agrega al select y el insert del periodo sucesor lo lleva. HALLAZGO DE AUDIT sobre 59a48dce, y era grave: habia DOS derivaciones del mismo hecho con fallbacks DISTINTOS. effectiveEstadoId caia al periodo que se CIERRA; estadoEfectivo -el que decide esBaja- caia a la FICHA. Discrepaban exactamente en la poblacion que este ticket repara, porque todo periodo abierto por una edicion anterior tiene estado_id NULL por el propio defecto. Resultado: la primera edicion despues del deploy sobre uno de esos vehiculos leia NULL y lo escribia en el periodo sucesor, propagando el daño UN PERIODO MAS ADELANTE justo en las filas para las que se escribio el arreglo. FB444EP es una de ellas. Corregido en 028a00d0: UNA sola variable estadoEfectivo, ficha primero, currentHistorial degradado a segunda opcion y solo para un vehiculo sin fila de colectivo. Consumida por esBaja y por el insert del sucesor. Ademas, guard de NaN en el parseo de estadoId: sin el, un estado no numerico entraba como NaN hasta el INSERT. Tira en vez de escribir - un estado no numerico es defecto del llamador, no un valor a coercionar. QUE CUENTA COMO VERIFICACION, y no existe todavia: una edicion por el FORMULARIO sobre un vehiculo cuyo estado en el historial es NULL y en la ficha NO lo es -FB444EP califica-, leyendo despues estado_id en la fila sucesora. Si sale el valor de la ficha, el arreglo corre; si sale NULL, no. Es una escritura en DEV, asi que es de db02 o mia, no de audit. Ninguna afirmacion de este ticket esta respaldada por una corrida: audit lo limpio LEYENDO, no ejecutando. BLOQUEADO POR: lo mismo que 332 - una credencial de dev01 que funcione y que no sea la cuenta de Elazar.
-
2026-09-07 16:58 - CORRECCION DE RADIO, error mio. Antes de este evento yo describi el alcance de 331 como 'todo vehiculo alguna vez editado por el formulario', citando los 378 que midio db02. Mal atribuido: el conteo era de db02, el mecanismo lo puse yo, y los numeros no se parecen. Desglose por origen de la fila rank-1 detras de los 378 (db02, DEV, 2026-09-07 ~16:56): import 375, app 2, sin fila 1. Techo independiente: solo 5 vehiculos distintos tienen alguna fila origen='app' no borrada en rutap.vehiculo_historial_normalizado en toda su historia. RADIO REAL DE 331 EN DEV: **5 vehiculos**, no 378. El defecto de arrastre solo podia dispararse sobre una fila escrita por el formulario. Los otros 375 son otro mecanismo -el import no popula estado_id en la capa normalizada- y viven en MOVILBA-333. Esto NO cambia la gravedad del hallazgo 6 de audit ni el arreglo: propagar NULL hacia adelante sobre las filas que el arreglo existe para reparar seguia siendo lo que hacia, y se corrigio en 028a00d0. Cambia cuantas filas podian sufrirlo. OJO CON EL SUJETO DE VERIFICACION: AA033TK (6719) esta en el grupo import, asi que NO ejercita el camino de escritura de 331 hasta que el formulario le escriba una fila app. Editarlo igual sirve -produce la primera fila app de ese vehiculo y la asercion pre-establecida sobre estado_id en el sucesor se mantiene- pero un pase ahi NO cubre a los otros 374.
-
2026-09-07 17:01 - CORRECCION DE MI PROPIA CORRECCION. En el evento anterior escribi que AA033TK (6719), por ser de origen import, NO ejercita el camino de escritura de 331 'hasta que el formulario le escriba una fila app'. Eso sobre-corrige y esta mal: la EDICION ES la que escribe la fila app, no hay nada que esperar. AA033TK es el sujeto IDEAL para el hallazgo 6 de audit, no uno inadecuado. Su estado es exactamente el escenario del hallazgo: currentHistorial.estado_id NULL -la fila de import- y ficha estado_actual_id 116. El codigo PRE-arreglo habria leido el periodo que se cierra y escrito NULL hacia adelante; el POST-arreglo lee la ficha y escribe 116. O sea que el sucesor llevando 116 falsifica el bug al primer intento. Lo unico correcto de mi caveat: un pase ahi no dice NADA de los otros 374, cuyos NULL existentes son MOVILBA-333 y no los repara ninguna edicion. Correccion de audit-mba-l-cc.
-
2026-09-07 23:00 - EL DEFECTO MEDIDO EN CRUDO SOBRE FB444EP, con provenance. Medido por db02-mba-l-cc sobre DEV, rutap.vehiculo_historial_normalizado, las tres filas del vehiculo que reporto Eugenia. Las tres origen='app', creado_por 20425668650, todas del 2026-09-07: id 80587 - creado_en 15:39:51.813 - normalizado_por app-create-colectivo - alta 2026-09-06 - baja 2026-09-07 - **estado_id 116** - expte_alta EX-2026-39357754-GCABA-DGGSM id 80588 - creado_en 15:40:24.759 - normalizado_por app-editar-colectivo - alta 2026-09-07 - baja 2026-09-07 - **estado_id NULL** - tramite_id 318 id 80589 - creado_en 15:42:13.891 - normalizado_por app-editar-colectivo - alta 2026-09-07 - baja NULL - **estado_id NULL** - tramite_id 318 Alta a las 15:39 con estado 116, editado 33 segundos despues, editado otra vez 109 segundos mas tarde. Cada edicion cerro el periodo anterior y abrio un sucesor, y **cada sucesor perdio el estado**: 116 -> NULL -> NULL. La UNICA fila que llevo estado alguna vez es la que escribio el ALTA. Esto es MOVILBA-331 en crudo, sobre el vehiculo reportado, sin necesidad de razonar desde el codigo. DE PASO, ACLARA UN FALSO POSITIVO: el 'ALTA Y BAJA EL MISMO DIA' que marco proxy-mba-w-cc en el panel de historial NO es una anomalia de datos. 80588 abre el 07/09 y cierra el 07/09 porque llego una tercera edicion dos minutos despues. Es la cadena de ediciones registrada fielmente. proxy lo marco como observado y explicitamente NO lo diagnostico, que fue lo correcto. Y confirma [[reference_normalizado_por_nombra_al_que_abrio_el_periodo_nunca_al_que_lo_cerro]]: 80587 dice 'app-create-colectivo' aunque lo cerro una edicion. SIGUE SIN VERIFICARSE el arreglo: esto mide el defecto PRE-arreglo, no el post. Falta la edicion sobre AA033TK (6719) con la asercion ya pre-establecida.
-
2026-09-07 23:05 - VERIFICADO. Medido por db02-mba-l-cc a las 23:03:05, despues del guardado de proxy-mba-w-cc de 23:01:48-53 sobre AA033TK/6719 por el formulario real de dev01 v5.5.53. La asercion estaba pre-establecida ANTES de la corrida y se cumple en las tres partes: 1. SUCESOR con estado: id **80590** - vehiculo 6719 - dominio AA033TK - origen app - normalizado_por app-editar-colectivo - entidad 68 - linea 134 - **estado_id 116** - fecha_alta 2026-09-07 - fecha_baja NULL - expte_alta vacio - tramite_id 318 - creado_en 23:01:51.475711. 2. El periodo anterior 75742 CERRADO con fecha_baja 2026-09-07. 3. v_vehiculos_hist_ultimo para 6719 resuelve **estado_id 116** por historial_id 80590. A las 22:58 era NULL, asi que **no pudo pasar en vacio**. Cardinalidad 2418/2418 sin cambios. EL CONTRASTE QUE LO HACE UNA MEDICION Y NO UNA COINCIDENCIA: sobre FB444EP, con el codigo VIEJO, la misma operacion produjo 116 -> NULL -> NULL en las filas 80587/80588/80589. Sobre AA033TK, con el codigo NUEVO, produce 116. Mismo escritor, misma tabla, misma forma de edicion, resultado opuesto. Y 6719 ejercita la rama REPARADA, no la segura: currentHistorial.estado_id era NULL (fila de import) y beforeColectivo.estado_id era 116, o sea exactamente la divergencia del hallazgo 6 de audit. Con el fallback viejo habria escrito NULL. DE PASO, 315 vuelve a pasar sobre una ESCRITURA REAL y no sobre un no-evento: ficha 6719 sigue en entidad 68 / TRANSPORTES NUEVE DE JULIO SAC / linea_id 134 / numero_linea 109 / estado Alta. COBERTURA - lo que esto NO prueba: - UN vehiculo, UNA edicion. No es una medicion de poblacion. - El formulario NO mando estado, asi que se ejercito el ARRASTRE desde la ficha. NO se ejercito el camino donde la pantalla manda un estado nuevo, ni una BAJA. - No cubre los 375 importados de MOVILBA-333, que ninguna edicion repara. - El guard de NaN de :964 no se ejercito.
-
coder-mba-l-ca
-
Assignment reconciliation:028a00d0 is an ancestor of current9dfd4fb0 (git merge-base exit0). Code still resolves one estadoEfectivo at repositories/vehiculos.ts1129 and inserts it into successor at1266. Tracker already has positive real-form DEV control successor80590/6719 state116 on Sep7 23:05. No duplicate fix justified; raised stale backlog status to coder02; new-state/BAJA controls remain distinct uncovered cases.
-
2026-09-08 01:27 - Reconciliacion de estado (coder-mba-l-ca sobre 9dfd4fb0/c95f9196): el arreglo ya estaba shipeado el 09-07 23:05 (59a48dce/028a00d0, sucesor 80590 sobre el vehiculo 6719 con estado 116); el item quedo en backlog por deriva de estado, no por un defecto vivo. SIN COBERTURA declarada: el camino de estado NUEVO y el de BAJA no fueron ejercitados. Se cierra por eso; si aparece una fila abierta por edicion sin estado_id se reabre nombrando la fila.
bug
5w ago by wi-cli-venus
5w ago
2026-09-08 04:27