Nada cierra nunca un estado_id de vdc: el reconciliador solo re-abre, asi que un dominio que el libro cierra queda en ALTA para siempre
Verificado por coder03 contra pg_get_functiondef/prosrc en PROD, independientemente del lead de audit (213) y de db02. rutap.reconciliar_estado_abierto_snapshot es el UNICO UPDATE rutinario sobre vehiculos_datos_colectivos.estado_id, y es unidireccional: el unico valor que llega a insertarse en rutap_estado_reconcile_targets.estado_objetivo es v_alta_id, y toda la seleccion de targets filtra btrim(coalesce(fecha_baja,''))='' (solo filas abiertas). No hay ninguna rama que apunte a BAJA. El nombre de la funcion lo dice - reconciliar_estado_ABIERTO - asi que es un alcance declarado, no un bug escondido, pero el efecto es que la unica via por la que una fila vdc existente puede cambiar de estado va en una sola direccion. rutap.materializar_snapshot_raices si escribe BAJA, pero solo en el INSERT inicial (CASE WHEN s.fecha_baja_n IS NULL THEN v_alta ELSE v_baja), y ese INSERT esta guardado por WHERE NOT EXISTS: nunca corre para una fila que ya existe. Consecuencia: un dominio que el libro cierra DESPUES de que su fila vdc fue creada queda en ALTA indefinidamente; no se auto-corrige y cada cierre futuro del libro suma uno mas. Reencuadra las fallas Grupo A de MOVILBA-213: no son atraso de import, son este hueco permanente atrapando los dominios que el libro cerro mas recientemente. Comparte causa raiz con MOVILBA-486 (vdc no tiene via de update salvo la unica hardcodeada) pero se separa a proposito: 486 es una decision de contrato del importador, esto es un arreglo mas angosto y shippeable aparte.
Activity
-
Subsumido por MOVILBA-486. El diseño (docs/reference/movilba-486-reconcile-design.md, §2/§4) pone estado_id como una columna mas del bloque de asignacion incondicional, tomada de estado_derivado de la fila vigente del snapshot, asi que el camino de BAJA que este item reclamaba lo cubre esa funcion. No es un fix aparte; no se trabaja en paralelo.
-
FALSO HOY, subsumido por 486. Medido por db03-mba-l-cc el 2026-09-23, PROD y DEV por separado, estado resuelto por opciones (valor_opcion) y nunca por id crudo. PROD 2413 vehiculos: 814 cerrados en el libro, cerrados con vdc en ALTA = CERO, cerrados con vdc en BAJA = 814, cerrados sin vdc activo = 0, abiertos con vdc en BAJA = 0. DEV mismo conteo salvo un 1 en abiertos+BAJA, que es 4382/AF894KE, dato de prueba de origen app. El ticket describe el reconciliador PRE-486: desde 486 rutap.reconciliar_snapshot es BIDIRECCIONAL e incondicional - estado_objetivo = CASE WHEN la fila import vigente tiene fecha_baja NULL THEN ALTA ELSE BAJA END - y corre para todo vehiculo del snapshot. Evidencia de que efectivamente disparo, que es lo que separa 'existe el escritor' de 'el escritor corrio': vdc_archive tiene 408 filas UPDATE en PROD y 3524 en DEV cuyo estado previo era ALTA y el actual BAJA. Censo de escritores de vdc.estado_id, por prosrc, identico en las dos bases: reconciliar_snapshot (UPDATE), materializar_snapshot_raices (INSERT, ALTA/BAJA por fecha_baja), y el camino app en vehiculos.ts via resolverEstadoColectivo. NO son escritores fn_cascade_soft_delete_vehiculo (solo borrado_en), fn_archive_vehiculos_datos_colectivos (escribe el archive) ni proyectar_snapshot. Triggers sobre vdc: solo archive y soft-delete; sin reglas; estado_id no es generada. NO EJERCITADO: una corrida del reconciliador contra un snapshot NUEVO - lo medido es el estado DESPUES de la ultima corrida, no la corrida
-
Medido 2026-09-23 en PROD y DEV por separado: 0 vdc en ALTA bajo un cierre del libro (814 cierres, los 814 en BAJA). reconciliar_snapshot (486) asigna estado_id en las dos direcciones; el texto del ticket describe el reconciliador anterior. Subsumido por 486.