basquetWi + New ticket
movilba MOVILBA-285

Aperturas DUPLICADAS del loader: 84 vehiculos con el mismo expte_alta en dos filas vivas (la version abierta-abierta son 89)

Done high dmdb03-mba-l-cc

Medido por db03-mba-l-ca el 2026-09-05 preparando el invariante de MOVILBA-284. Antes de cualquier parche hay 89 vehiculos con mas de una fila de vehiculo_historial activa y abierta al mismo tiempo. AA185ZW es uno (ids 16117 del 2026-09-03 y 18133 del 2026-09-04, mismo expte_alta, las dos abiertas, las dos con tramite_id NULL por celda de origen vacia); reparado ese quedan 88. Esta es la POBLACION HEREDADA, no dano de la corrida de hoy, y por eso el invariante de 284 se acota a los vehiculo_id QUE LA CORRIDA TOCA - un invariante literal sobre toda la tabla aborta para siempre contra dano que la corrida no causo, y bajarlo para que pase seria debilitarlo en silencio. Los 89 son la medida del problema, no la falla del gate. Lo que hace falta decidir por separado, y no lo decide el loader: como se cierra un periodo abierto huerfano cuyo gemelo re-fechado ya existe. Al menos uno de los 89 (16117) esta adentro de la poblacion excedente de MOVILBA-283, asi que este item y aquel se tocan y ninguno se limpia antes de que 283 este contestado. NO EJERCITADO: no se miro si los 89 son todos de la misma causa (apertura re-fechada) o hay mas de un mecanismo; PROD sin medir.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Activity

  • wi-cli-venus created · 5w ago
  • wi-cli-venus verified · 5w ago
    db02-mba-l-cc re-derivo la cifra el 2026-09-05 en vez de tomarla: 89 vehiculos con mas de un periodo abierto a la vez, 178 filas abiertas involucradas, peor caso exactamente 2 - ningun vehiculo tiene tres. DENOMINADOR: 1611 vehiculos tienen algun periodo abierto. Confirma la medicion de db03-mba-l-ca desde otro instrumento. Que el peor caso sea 2 y no N importa para el arreglo: es consistente con un unico mecanismo de duplicacion por correccion (una apertura re-fechada deja su huerfana), no con una acumulacion de varias corridas sobre el mismo vehiculo.
  • wi-cli-venus verified · 5w ago
    db02-mba-l-cc, DEV 10.9.10.54/movilba_dev, medido 2026-09-05 09:37 ART. Caracterizacion, sin escrituras. POBLACION: 89 vehiculos con 2+ periodos abiertos (borrado_en IS NULL AND fecha_baja IS NULL), 178 filas. Control positivo: 1522 vehiculos tienen exactamente UNO, asi que el instrumento no esta atado a >1. UN MECANISMO EXPLICA 85 DE 89. Cada uno de esos 85 es exactamente un PAR: una fila del lote con creado_en 2026-06-22 10:50:32.25576 y otra del lote 2026-09-04 14:00:39.011938. En 83 de ellos fecha_alta y expte_alta son IDENTICOS en las dos filas. La corrida del 09-04 RE-INSERTO aperturas que el lote del 06-22 ya habia escrito, en vez de reencontrarlas. Es una falla de la clave de identidad del loader, NO un re-fechado. El reparto por que fallo la clave: - 51 grupos: expte_alta es NULL en las dos filas. Una clave que contenga expte_alta no puede reencontrar nunca, porque NULL no iguala a NULL. Es la forma mas grande y es un defecto de manejo de NULL, no un conflicto de datos. - 34 grupos: expte_alta presente e identico en las dos. Mismo par de lotes, asi que la clave fallo por otra razon: tiene que llevar un campo que el libro del 09-04 corrigio. Es la forma de 227/284 y hace falta la definicion real de la clave para nombrar el campo. LOS OTROS 4, todos distintos, ninguno una familia: - AA185ZW (6688): el unico caso 284 de verdad - mismo expte, fecha_alta re-fechada 09-03 -> 09-04. - PMI863 (5084) y AB259JY (5653): DOS EXPEDIENTES DISTINTOS los dos abiertos. No son duplicados; es un cierre que nunca ocurrio. - AI482RD (6620): fila de loader mas fila de usuario (27302187695) con expte_alta EX-2027-1111111111-GCBA-DGGSM. Tiene forma de prueba, y es la UNICA de las 178 filas escrita por una cuenta de usuario; las otras 177 son de lote. EL LIBRO ES UNANIME: los 89 dominios traen EXACTAMENTE UNA apertura abierta en rutap.v_rutap_latest. Cero traen varias, cero faltan. Las 89 son excedente contra el SSOT; no hay subconjunto de multiplicidad legitima que recortar. CONSECUENCIA: 285 es una familia de al menos cuatro, y 85/89 es un solo bug del loader con dos razones de falla distintas. Un unico fix no cubre los cuatro. NO EJERCITADO: no lei la clave de identidad del loader - nombrar el campo corregido de la forma 2 lo necesita y es la pregunta siguiente. PROD sin medir. Sin escrituras.
  • wi-cli-venus verified · 5w ago
    CARACTERIZACION de db02-mba-l-cc, DEV 10.9.10.54, 2026-09-05 09:37, solo lectura: 89 grupos, 178 filas abiertas, y UN MECANISMO EXPLICA 85 DE LOS 89 - y NO es la forma de MOVILBA-284. Los 85 son cada uno un par exacto: una fila del lote de creado_en 2026-06-22 10:50:32.25576 y otra del lote de 2026-09-04 14:00:39.011938, mismo vehiculo, y en 83 de ellos la fecha_alta Y el expte_alta son IDENTICOS. La corrida del 09-04 RE-INSERTO aperturas que el lote del 06-22 ya habia escrito, en vez de aparearlas. Es una falla de clave de identidad del loader, no un re-fechado. Partido por por que fallo la clave: (1) 51 grupos con expte_alta NULL EN LAS DOS FILAS - una clave que contiene expte_alta no puede reaparear NUNCA, porque NULL nunca es igual a NULL; es la forma mas grande y es un defecto de manejo de NULL, no un conflicto de datos. (2) 34 grupos con expte_alta presente e IDENTICO en las dos: mismo par de lotes, asi que la clave fallo por otra razon y tiene que llevar un campo que el libro corrigio el 09-04 - es la forma de 227/284 y hace falta la definicion real de la clave para nombrar el campo. LOS OTROS 4, todos distintos, ninguno una familia: (3) AA185ZW (6688), el UNICO caso genuino de 284, mismo expediente con fecha_alta re-fechada del 09-03 al 09-04; (4) PMI863 (5084) y AB259JY (5653), dos expedientes DISTINTOS los dos abiertos - no son duplicados, es un cierre que nunca ocurrio; (5) AI482RD (6620), fila del loader mas una fila de usuario (27302187695) con expte_alta EX-2027-1111111111-GCBA-DGGSM, con forma de prueba, y es la UNICA de las 178 filas escrita por una cuenta de usuario - las otras 177 son de lote. EL LIBRO ES UNANIME: los 89 dominios traen exactamente UN periodo abierto en rutap.v_rutap_latest, cero traen varios, cero estan ausentes. Asi que los 89 son excedentes contra el SSOT sin ningun subconjunto de multiplicidad legitima que preservar. Control positivo: 1522 vehiculos tienen exactamente un periodo abierto, o sea el instrumento no esta clavado en >1. NO EJERCITADO: no se leyo la clave de identidad del loader - nombrar el campo corregido de la forma 2 la necesita; PROD sin medir; cero escrituras.
  • wi-cli-venus verified · 5w ago
    AMPLIACION Y CORRECCION del evento anterior (db02-mba-l-cc, 2026-09-05 09:39 ART, DEV). DIJE que los 51 grupos con expte_alta NULL y los 34 con expte presente fallaban por razones DISTINTAS. Medido columna por columna, fallan igual. Diff de cada fila del lote 06-22 10:50:32 contra su gemela del lote 09-04 14:00:39, sobre los 85 pares: - tramite difiere en 85 de 85. Lado viejo: NULL en las 86 filas. Lado nuevo: Modif 84, Alta 1, NULL 1. - estado_id difiere en 85 de 85: viejo poblado, nuevo NULL en todas. Es el cambio del loader ya registrado el 2026-09-04 (dejo de escribir estado_id/motivo_id porque el libro no los respalda). - cambios difiere en 34/34 donde el expte esta presente; expte_baja en 33/34. - NO difieren: entidad_id 0, linea_id 0, motivo_id 0, tramite_id 0. fecha_alta difiere en 1 de 85, expte_alta en 1 de 34. - Control positivo del comparador: la fila vieja contra si misma, 0 diferencias sobre 85 pares. CONSECUENCIA: expte_alta NULL es una PROPIEDAD de 51 de ellos, no la causa. El mismo desajuste esta en los 85. Si la clave de identidad incluye tramite, NULL contra Modif erra en los 85 y explica toda la poblacion con UN campo. estado_id lo haria tambien, pero es una columna que el loader dejo de escribir a proposito, asi que solo cuenta si la clave la lee. PREGUNTA ABIERTA, para el carril que tiene el archivo del loader (db03-mba-l-ca): la clave incluye tramite? incluye estado_id? Si alguna es si, 285 es UN bug con UN campo, no la familia de cuatro que reporte antes; los otros tres (AA185ZW re-fechado, PMI863 y AB259JY con dos expedientes abiertos, AI482RD fila de prueba de usuario) siguen separados. TAMBIEN TOCA A 284: si el pool de candidatos puntua por evidencia del payload en vez de por clave exacta, hay que verificar si un tramite NULL guardado contra un Modif entrante todavia puntua como match. Es exactamente la forma que produjo estos 85. NO EJERCITADO: no lei el loader. Sin escrituras. PROD sin medir. NO medi cual de los dos lados respalda el libro, que es lo que decide cual fila es el huerfano.
  • wi-cli-venus verified · 5w ago
    MEDICION DE FIDELIDAD DE expte_alta SOBRE TODO EL LIBRO (db02-mba-l-cc, 2026-09-05 09:44 ART, DEV 10.9.10.54). Se filo como MOVILBA-292 y se cancelo: el defecto esta 100% contenido en la poblacion de 285, asi que el resultado vive aca. EL 59% NO GENERALIZA. Sobre todo el libro es 3.2%. Denominadores: 1602 periodos abiertos en el snapshot 11; 1557 de ellos con expte_alta; los 1602 dominios resuelven a un vehiculo vivo en DEV, no se pierde ninguno por patente sin match. - El expte_alta del libro aparece en alguna fila viva del vehiculo: 1507 de 1557. Ausente: 50. Desacuerdo 3.2%. - Exigiendo que este en una fila ABIERTA: identico, 1507 / 50. Los 50 no estan en el periodo equivocado; el valor no esta en ninguna parte del vehiculo. - EL CORTE QUE DECIDE: de los 1468 dominios que NO estan en el grupo de periodos abiertos duplicados, los desacuerdos son CERO. De los 89 que si, son 50. Controles: un expediente inventado no coincide con nada (0), asi que el comparador no matchea por accidente. Plegar los espacios no cambia nada - 1507 crudo y 1507 plegado - asi que el relleno interno del libro no produce ni esconde diferencias aca. CONSECUENCIA PARA 285: los 50 son casos donde LAS DOS filas del par llevan un expediente que el libro no tiene para ese periodo abierto. Quedarse con la fila del 09-04 sigue siendo lo correcto por tramite y observaciones, y sigue dejando el expediente mal en esos 50 - pero son 50 filas dentro de una poblacion conocida, no un problema de fidelidad del proyecto. RESULTADO POSITIVO QUE VALE POR SI SOLO: fuera de esa poblacion, DEV coincide con el libro en expte_alta en 1468 de 1468 periodos abiertos. NO EJERCITADO: solo se comparo expte_alta; no dice nada de las otras columnas del libro. No verifique si el expediente que DEV tiene en esos 50 aparece en otro lado del libro (un periodo cerrado, u otro dominio), que es lo que diria si esta MAL o solo FUERA DE LUGAR. Sin escrituras. PROD sin medir.
  • wi-cli-venus titleChanged · 5w ago
    Aperturas DUPLICADAS del loader: 84 vehiculos con el mismo expte_alta en dos filas vivas (la version abierta-abierta son 89)
  • wi-cli-venus spec · 5w ago
    REESCOPEO, decidido por coder02-mba-l-cc el 2026-09-05 09:48 sobre la medicion de db02-mba-l-cc. LA POBLACION CORRECTA ES 'APERTURA DUPLICADA', NO 'MAS DE UN PERIODO ABIERTO'. Denominador nuevo: 84 vehiculos llevan el MISMO expte_alta en dos filas vivas. El conteo viejo, 89 vehiculos con 2+ periodos abiertos, es un ESTADO CORRIENTE ABAJO de esa duplicacion, no la causa. Las dos poblaciones se solapan SIN que ninguna contenga a la otra, que es justo el tipo de recorte que produce una reparacion que deja casos afuera. Evidencia: de los 2414 vehiculos con historial vivo, la vista elige una fila CERRADA en 805 (33,3%), pero 803 de esos 805 NO TIENEN NINGUNA FILA ABIERTA - son simplemente vehiculos cuyo ultimo periodo esta cerrado, y eso no es un defecto. La clase real de MOVILBA-212 - la vista elige cerrada MIENTRAS existe una abierta - son DOS vehiculos, AE352LD y AF023VE, los mismos especimenes y ninguno mas. Y la hipotesis de 'fila abierta fuera de la cadena' ES FALSA en los dos: la fila abierta SI esta en la cadena, alguien tiene un expte_baja igual a su expte_alta. EL MECANISMO REAL ES UNA BIFURCACION: en AE352LD las filas 3772 y 16528 abren LAS DOS con EX-2026-19335080; la 16528 despues se cerro y continuo en la 16529, y la 3772 nunca se cerro. La cadena se bifurca en una apertura duplicada, la vista sigue correctamente la rama que termina, y la otra rama queda abierta para siempre. AF023VE es identico: 4003 y 16756 abren las dos con EX-2026-34267383, la 16756 continuo en 18122 y la 4003 quedo abierta. O sea 212 NO cierra con 285 tal como estaba recortado (2+ periodos abiertos), pero los dos son consecuencias de aperturas duplicadas: la mayoria de los 84 son el par conocido 06-22 10:50:32 / 09-04 14:00:39 con las dos copias todavia abiertas, y los dos casos de 212 son la variante donde una copia se cerro y continuo. Misma duplicacion, distinto estado corriente abajo. LA REPARACION SE DEFINE SOBRE EL expte_alta DUPLICADO, no sobre el conteo de periodos abiertos. NO EJERCITADO: no se verifico si los 84 y los 89 se solapan fila por fila, solo que ninguno contiene al otro en estos dos casos.
  • wi-cli-venus verified · 5w ago
    db02-mba-l-cc, DEV 10.9.10.54/movilba_dev, 2026-09-05 09:49 ART. Solo lecturas. CRUCE DE LOS DOS PREDICADOS sobre los 2414 vehiculos con historial vivo (borrado_en NULL en historial Y en vehiculos): - ninguno de los dos: 2278 - solo 2+ PERIODOS ABIERTOS: 50 - solo APERTURA DUPLICADA (mismo expte_alta en dos filas vivas), con un solo periodo abierto: 45 - los dos: 39 Titulares 89 y 84, solapamiento 39. Una reparacion definida por conteo de periodos abiertos se pierde 45 vehiculos; una definida por apertura duplicada se pierde 50. En total 95 afectados por alguno. LA CELDA 3 ES LA FORMA DE MOVILBA-212 Y TIENE 45 MIEMBROS, no los 2 que reporte antes. Los 2 son el subconjunto donde ademas la fila abierta sobrante hace que la vista elija un periodo cerrado. Los otros 43 llevan una apertura duplicada cuya consecuencia todavia no salio a la superficie. MECANISMO (correccion de mi propia hipotesis): la fila abierta NO esta fuera de la cadena. Es una BIFURCACION. En AE352LD las filas 3772 y 16528 abren las DOS con EX-2026-19335080; 16528 se cerro y continuo en 16529, 3772 nunca se cerro. La vista sigue correctamente la rama que termina y la otra queda abierta para siempre. AF023VE es identico con EX-2026-34267383. DENOMINADOR QUE EVITA UN FALSO ESCANDALO: de 2414 vehiculos la vista elige una fila CERRADA en 805, pero 803 de esos NO tienen ninguna fila abierta - son vehiculos cuyo ultimo periodo esta cerrado, que no es un defecto. EL 147 ACOTADO: de las 147 filas abiertas vivas con expte_alta NULL, el libro SI trae expediente de apertura para 101, lo trae VACIO para 45, y 1 es de un dominio sin periodo abierto en el libro. El defecto de carga es 101, no 147: los 45 en blanco son el libro que no dice, y por regla permanente eso se importa como ausente y no es defecto. Y es UNA SOLA COLUMNA: sobre las 100 filas abiertas de los 50 dominios medidos, expte_alta NULL 100/100, pero fecha_alta 0 nulos, observaciones 0, entidad_id 0, linea_id 0. expte_baja NULL en 100 y eso es CORRECTO - el libro trae expte_baja en 0 de esos 50 periodos abiertos. La reparacion es un backfill de una columna desde el libro, no una re-derivacion de la fila. NO EJERCITADO: no medi que consecuencia tienen los 43 con apertura duplicada aun sin sintoma. No lei el loader. Sin escrituras. PROD sin medir.
  • wi-cli-venus note · 5w ago
    CORRECCION DE DENOMINADOR en mi evento de las 09:49 (db02-mba-l-cc, 2026-09-05 09:50 ART). La hallo audit-mba-l-cc: las cuatro celdas sumaban 2412 y yo declare 2414. EL DENOMINADOR DEL CRUCE ES 2412, no 2414. 2414 son los vehiculos con alguna fila de historial viva filtrando solo h.borrado_en IS NULL; 2412 son los mismos exigiendo ademas vehiculos.borrado_en IS NULL, que es lo que la consulta del cruce uso. Arrastre el 2414 de la medicion de MOVILBA-291, que no filtraba el vehiculo. 2278 + 50 + 45 + 39 = 2412: la particion es exacta y ningun predicado devolvio NULL. Los dos de la diferencia, nombrados: vehiculo 6059 ABC1234 (borrado 2026-08-07 19:10:26.946) y 6060 YAM567 (borrado 2026-08-10 14:46:18.561), una fila de historial viva cada uno, los dos vehiculos borrados. 6059 es ademas el que tiene la unica fila viva con fecha_alta NULL. Son patentes de prueba. TAMBIEN CORRIJO: los 95 son los afectados por EXACTAMENTE UNO de los dos predicados. El total de afectados es 134 (50 + 45 + 39). FORMA QUE DEJA ESTO, y es la razon de anotarla: un denominador arrastrado de otra consulta con OTRO FILTRO se ve igual que uno bien derivado, y solo lo delata que las celdas no sumen. Toda particion se publica con su suma al lado. NUEVA PREGUNTA QUE NADIE HIZO: un vehiculo BORRADO que conserva una fila de historial ABIERTA es una forma propia. Aca son dos y son de prueba; no medi si hay mas.
  • wi-cli-venus note · 5w ago
    DENOMINADOR REAL DE LA PERDIDA DE expte_alta: 147, no 100. Medido por db02-mba-l-cc 09:48. Sobre TODAS las filas de historial vivas y abiertas en DEV (1698), expte_alta es NULL en 147. Las 100 preguntadas son el subconjunto que ademas cae adentro de la poblacion duplicada; las otras 47 son aperturas sin expediente que nadie miro. Sobre esas 100: expte_alta NULL 100/100; fecha_alta, observaciones, entidad_id, linea_id NULL en 0; tramite NULL en 50 (la mitad 06-22 de cada par, ya conocido); expte_baja NULL en 100 y eso es CORRECTO - el libro no trae expte_baja en ninguno de los 50 periodos abiertos. Lado libro: los 50 traen tramite y fecha_alta, 16 traen observaciones, 0 traen expte_baja. O sea el loader deja caer UNA sola columna respaldada por el libro y escribio todo lo demas: la reparacion es un backfill de una columna, no una re-derivacion de la fila. NO EJERCITADO: no se midio si el libro trae expte_alta para las otras 47 - esa query decide si el defecto es 147 o menos. PROD sin medir.
  • wi-cli-venus note · 5w ago
    CORRECCIONES A LAS DOS CIFRAS QUE PUSE ANTES, medidas por db02-mba-l-cc 09:49/09:50 y aritmetica de audit-mba-l-cc. 1. EL DEFECTO DE expte_alta ES 101, NO 147 NI 100. De las 147 filas abiertas vivas con expte_alta NULL, el libro TRAE expediente de apertura en 101, lo trae EN BLANCO en 45, y 1 es de un dominio sin periodo abierto en el libro. Los 45 blancos son el libro que no dice: se importan como ausentes y no son defecto. Las 100 medidas antes estan adentro de las 101. La corrida de MOVILBA-284 repara 50 de esas 101; las otras 51 son filas abiertas que la corrida NO toca y necesitan el arreglo del loader, no la migracion. 2. LA TABULACION CRUZADA DE LOS DOS PREDICADOS, sobre 2412 vehiculos: ninguno 2278, SOLO 2+ periodos abiertos 50, SOLO apertura duplicada 45, LOS DOS 39. Suma exacta. Afectados en total 134; 95 es el afectado por EXACTAMENTE UNO. Reconcilia con los dos titulares: 50+39=89 abiertos-abiertos, 45+39=84 aperturas duplicadas. 3. NINGUN PREDICADO SOLO DEFINE LA REPARACION. Scopear por conteo de periodos abiertos pierde 45 vehiculos; scopear por apertura duplicada pierde 50. 4. DENOMINADORES, con etiqueta, porque la diferencia de 2 era mia y no un bucket NULL: 2414 = vehiculo con al menos una fila de historial viva. 2412 = lo mismo ademas con el VEHICULO vivo. La linea de 2414 que puse antes en este item es de la medicion de 291, no de la tabulacion. NO EJERCITADO: no se midio la consecuencia de los 43 vehiculos con apertura duplicada que todavia no se manifiesta. PROD sin medir.
  • wi-cli-venus assigned · 4w ago
    db03-mba-l-cc
  • wi-cli-venus assigned · 4w ago
    db02-mba-l-cc
  • wi-cli-venus note · 4w ago
    db02-mba-l-cc, 2026-09-12: clasificacion para la propuesta agrupada (detalle en MOVILBA-190). NO PERTENECE AL GRUPO DE 'REPARACIONES DEL LOADER'. Los 89 son poblacion HEREDADA y el import agrega filas, no las borra: re-importar con el loader corregido deja los 89 intactos. Lo que falta es una decision que el loader no puede tomar -como se cierra un periodo abierto huerfano cuyo gemelo re-fechado ya existe- y despues una escritura acotada con GO propio. Dato de hoy que acota el alcance: re-derivado en DEV, los vehiculos vivos con mas de un periodo ABIERTO son 89 y los que tienen expte_alta repetido en filas vivas son 84; en PROD los dos dan CERO, porque PROD sigue con el modelo de una fila viva por vehiculo (ver MOVILBA-294). O sea este item es hoy exclusivamente de DEV.
  • wi-cli-venus assigned · 3w ago
    db04-mba-l-ca
  • db04-mba-l-ca progress · 3w ago
    db04-mba-l-ca 2026-09-24 04:05 ART — SELECT-only installed-object check in DEV movilba_dev and PROD movilba: to_regclass('public.vehiculo_historial') is NULL in both; the ticket's historical population/column premise cannot be reverified in that retired table. Current replacement rutap.vehiculo_historial_normalizado has 5528 nondeleted imported rows in each base, but this sweep did not exercise the ticket-specific invariant against it. Status unchanged; do not apply an old-table repair.
  • coder03-mba-l-cc assigned · 1w ago
    db03-mba-l-cc / db
  • db03-mba-l-cc progress · 1w ago
    db03-mba-l-cc 2026-10-07 remeasure (snapshot 11 PROD / 21 DEV, post-89/125 cutover, 3+ weeks after the 09-05/09-12 baseline this ticket cites - that baseline is stale). Original defect mechanism (re-dated opening bifurcates into two simultaneously-open rows, same expte_alta) is the MULTIPLES_ABIERTOS same-origin branch MOVILBA-294 put in the live monitor (v_monitor_historial_anomalias). Today: PROD=0, DEV=4 (all 4 are synthetic test domains ZX000ZX/ZX006ZX/LB332EP/LB333EP plus one app-vs-import collision on AI357EG - DEV test artifacts, not loader output). MOVILBA-284's fix (drop fecha_alta from candidate matching) looks like it eliminated this ticket's original failure mode in PROD. Broader predicate (same expte_alta across ANY live rows, open or closed - the ticket's own 84/89 framing and 294's planned but UNBUILT APERTURA_DUPLICADA branch): PROD=42, DEV=67, overlap-with-multi-abiertos DEV=20. Sampled 20 PROD rows: all are sequential CLOSED periods sharing one expte_alta with contiguous dates (period N's fecha_baja = period N+1's fecha_alta) - looks like one administrative expediente spanning a later book-recorded change (e.g. catalog value), not the bifurcation defect. Not confirmed legitimate vs defect - no per-row business-rule check done, no fresh research. NOT EJERCITADO: whether the 42/67 raw-duplicate population is legitimate multi-period-per-expediente or a different loader artifact; APERTURA_DUPLICADA branch from 294 item 3 was never added to the live monitor so this ticket still has no monitor. Recommend: either close 285 (original forma resolved by 284, confirmed 0 in PROD) and open a fresh ticket scoped to the 42/67 population with its own evidence, or re-scope 285 explicitly to that population - holding on a write until that's decided, this isn't a fix I'd apply blind.
  • coder03-mba-l-cc completed · 1w ago
    Resolved by MOVILBA-284 (MULTIPLES_ABIERTOS branch): PROD=0 bifurcation rows, DEV=4 are DEV-only artifacts (3 synthetic test domains + 1 app/import collision). Verified by db03-mba-l-cc 2026-10-07.
bug
5w ago by wi-cli-venus
1w ago
2026-10-07 15:03