Los otros 105 grupos con historial activo duplicado que MOVILBA-255 NO repara: 86 con mas de una fila ABIERTA, 14 sin ninguna abierta, 5 fuera de forma
Re-derivado en DEV 2026-09-05 (db02). Los 213 grupos (vehiculo_id, fecha_alta) con mas de una fila ACTIVA de public.vehiculo_historial, 428 filas, se parten en CUATRO clases por forma, y la reparacion de MOVILBA-255 cubre solo la primera: 108 grupos - exactamente 2 filas, exactamente 1 abierta, 1 solo expte_alta. Es la clase de 255 (107 se reparan, 1 excluido). 86 grupos - MAS DE UNA FILA ABIERTA, 172 filas. ESTE ITEM. 14 grupos - NINGUNA fila abierta: dos o mas periodos cerrados que se solapan en la misma fecha_alta. 5 grupos - una sola abierta pero no cumplen la forma de 255 (mas de 2 filas, o expte_alta distinto entre ellas). POR QUE NO ENTRAN EN LA REPARACION DE 255: esa migracion elige la fila verdadera porque hay EXACTAMENTE UNA cerrada y UNA abierta, y el libro resuelve a UNA fila que coincide con la cerrada. Con dos o mas abiertas no hay 'la cerrada'; con ninguna abierta no hay nada que retirar. Aplicarles la regla de 255 INVENTA un desempate, que es justamente lo que el gate de tools/rutap-sync-prod.sql se niega a hacer y por lo que aborta. LO QUE HACE FALTA ANTES DE PROPONER UN ARREGLO, y ninguna de las tres clases lo tiene medido todavia: (1) cuantos de los 86 resuelven a UNA sola fila del libro por (dominio, fecha_alta) - si no resuelven, no hay criterio y la respuesta es una pregunta al tracker de Eugenia, no una migracion; (2) si las 14 son periodos realmente solapados en el libro o dos escrituras nuestras del mismo periodo; (3) los 5 caso por caso. SE ARREGLA POR CLASE, CON SU GATE CADA UNA. Y ninguna de las cuatro clases desbloquea el sync sola: su gate cuenta filas de estado actual y sigue abortando mientras quede cualquiera de las cuatro. NO EJERCITADO: no se comparo ninguna de las tres clases contra el libro, no se escribio ningun archivo y no se toco PROD. Esto es la particion medida y nada mas.
Activity
-
parent=#3387
-
db03-mba-l-cc
-
MOOT, closed on measurement 2026-09-18 db03 (SELECT only; inet_server_addr checked). The item describes duplicate ACTIVE rows in public.vehiculo_historial; that table no longer exists in either base (441 cutover; to_regclass NULL in DEV+PROD) and the reader is rutap.v_vehiculo_historial_normalizado_fuente_actual. Re-measured on the normalized history, live vehiculos, groups (vehiculo_id,fecha_alta) with >1 live row: PROD 16 groups/32 rows, ALL origen='import', all 32 are distinct book rows (5514 import rows = 5514 distinct (snapshot,fila_excel)), i.e. Alta+Modif pairs the book itself carries, incl. 14 with no open row and 2 with one; multiples_abiertos in PROD = 0. DEV 43 groups: 16 import-only (same 16 as PROD) + 27 containing origen='app' rows (DEV test data). No writer duplicates anything now; nothing to repair. NOT EXERCISED: whether Eugenia wants the 14 same-fecha_alta closed pairs confirmed as real overlapping periods (they are what the book carries, a question for the tracker, not a defect of ours). Live remainder of the same family: MOVILBA-294 (monitor label codes the retired model, 1760/2413 flagged in PROD).
-
Query behind the closing measurement (db03 2026-09-18, DEV+PROD, SELECT only): from rutap.vehiculo_historial_normalizado (base table; svc_nextjs has no SELECT on ..._fuente_actual) where borrado_en is null and vehiculo_id in (select id from vehiculos where borrado_en is null): group by (vehiculo_id, fecha_alta) having count(*)>1, tabulated by (n rows, n abiertas = fecha_baja is null, n distinct expte_alta, n origen='app'). PROD: 16 groups (9 x [2 rows, 0 open, 2 expte], 5 x [2,0,1], 2 x [2,1,2]), app=0 in all; the 32 rows are 32 distinct (rutap_snapshot_id, rutap_fila_excel). DEV: 43 groups = the same 16 + 27 with origen='app' rows.