Resolver a mano las 9 filas de historial ocultas con periodo abierto (4 pares de doble import + AG732SW)
Decision de db03-mba-l-ca (2026-08-31, dueño del import): las 9 son residuo legacy de import duplicado/anomalo, NO son candidatas al des-escondido masivo, NO entran en el write set del snapshot-import de MOVILBA-155, y NO son el gate de chasis de MOVILBA-89. Quedan como conjunto MANUAL EXPLICITO aca. LAS 9, leidas fila por fila contra PROD por coder02-mba-l-cc y de forma independiente por db02-mba-l-cc, con el mismo resultado. Cinco vehiculos, los cinco con su fila de vehiculos VIVA (borrado_en NULL), asi que ningun cascade las explica; borrado_por NULL, asi que ningun usuario tampoco: AD919PL ids 8933 / 8934 par IDENTICO (linea 131 / entidad 65 las dos) AE922FX ids 8247 / 9028 par que DIFIERE: 77/41 contra 131/65 AE971FE ids 8222 / 8972 par que DIFIERE: 77/41 contra 131/65 AE971FF ids 8244 / 8965 par que DIFIERE: 77/41 contra 131/65 AG732SW id 4608 sola, expte_alta VACIO, estado 116 En los cuatro pares, fecha_alta y expte_alta son IDENTICOS dentro del par: es el mismo tramite importado dos veces. Los cuatro dominios son exactamente los 4 que ya estaban medidos como "tenemos MAS filas que el libro". Es la forma Tipo B, salvo que aca se ocultaron LAS DOS copias con borrado_en en vez de limpiar una. AG732SW es de otra clase y ya tiene destino: esta registrado como ROTO EN EL LIBRO (alta de la fila vigente anterior a la baja de su propio tramite anterior, chasis partido en dos lineas), es pregunta abierta a Eugenia y no defecto nuestro. Ademas su borrado_en (2025-12-12) es ANTERIOR a su creado_en (2026-06-22), imposible para una columna de auditoria. VARIANTE DEL DEFECTO QUE APARECIO ACA: en una fila de cada par, borrado_en es igual a FECHA_ALTA, no a fecha_baja (8933: 2025-07-24 = 2025-07-24; 8247: 2025-07-08 = 2025-07-08). O sea que borrado_en no se sobrecargo solo para "periodo cerrado": tambien se uso para tapar la fila perdedora de un empate de import. POR QUE NO ALCANZA CON DEJARLAS OCULTAS (db02, y es el punto que justifica este item): el predicado fecha_baja IS NOT NULL las excluye correctamente de cualquier des-escondido, pero eso significa que quedarian INVISIBLES PARA SIEMPRE. Es exactamente el modo de falla de reference_el_libro_rutap_es_un_snapshot_no_un_ledger_el_import_reemplaza: una fila que nadie puede ver sobrevive a todo import futuro y ningun chequeo por cantidad la encuentra. ESTADO ACTUAL: los cinco vehiculos tienen exactamente UNA fila viva, asi que hoy no se renderiza nada mal. La anomalia es invisible y solo saldria a la luz con un des-escondido. QUE HAY QUE HACER: decidir por par cual copia sobrevive, contra el LIBRO y no contra el historial existente (la baseline normalizada sale del libro, decision de db03). Son 4 decisiones, no 8. AG732SW no se toca hasta que Eugenia conteste. NO HAY ESCRITURA PROPUESTA. Cualquier resolucion necesita GO por item y ensayo.
Activity
-
parent=#3171
-
coder03-mba-l-cc / coder
-
db03-mba-l-cc
-
db04-mba-l-ca
-
db03-mba-l-cc / db
-
db03 2026-10-08: premise fully superseded, closing. Not re-trusting the 2026-08-31 ids. This ticket's entire finding (9 rows, specific ids 8933/8934/8247/9028/8222/8972/8244/8965/4608, hidden forever via borrado_en=fecha_alta on the losing copy of a duplicate-import pair) was measured against the OLD public.vehiculo_historial table. That table is gone (to_regclass NULL, confirmed again this session closing MOVILBA-113 - rebuilt 2026-08-14 by rutap.vehiculo_historial_normalizado, itself reloaded multiple times since, current snapshot 11 loaded 2026-10-06). None of the 9 cited ids exist anywhere in the current table (checked directly by id - zero rows). Re-measured the actual current rows for the same 5 dominios fresh, by dominio not by id: - AD919PL: 6 clean chained rows (131/65 throughout), no duplicate, no borrado_en anywhere. The "par IDENTICO" finding does not reproduce at all. - AE922FX, AE971FE, AE971FF (the three "par que DIFIERE" dominios): each now has a clean chain of 5-6 rows (131/65) PLUS one extra row with fecha_alta=fecha_baja (same date, zero-duration) on linea 77/entidad 41 - the same 77/41 vs 131/65 split the old finding flagged, but now as a VISIBLE zero-duration historical row, not a borrado_en-hidden one. borrado_en is NULL on every row of all three. elegible_actual=true on all of them (none excluded from projection). - AG732SW: 4 clean chained rows, vigente period open since 2026-09-11, no borrado_en, no fecha_baja-before-fecha_alta impossibility (that symptom was itself an artifact of the old table's data, also gone). THE SPECIFIC HARM THIS TICKET WAS FILED TO PREVENT ("quedarian INVISIBLES PARA SIEMPRE", a row no unhide-sweep or row-count check can ever find) does not apply to the current rows: nothing here carries borrado_en, so there is no row rendered permanently invisible by that mechanism in the rebuilt table. NOT CLOSING AS "no residual anomaly" - there is a smaller, different, visible one: the zero-duration 77/41 row on 3 of the 4 original dominios (AE922FX id 206438, AE971FE id 206457, AE971FF id 206464). It is NOT this ticket's defect (not hidden, not a 9-row set, not matching any of the old ids) and is not actioned here. If it is worth tracking it is a new, separate, much smaller finding - leaving it unfiled since it reads as a legitimate same-day open/close book artifact (visible, in the book's own chain) rather than an import defect, and it carries no "invisible forever" risk the way the original did.
-
db03: premise gone - old table rebuilt 08-14, none of the 9 cited ids exist, current rows for the 5 dominios show no borrado_en-hidden duplicates. See nota.