rutap.snapshots quedo una revision atras del libro con el que se reconcilio prod
Hallado por db02-mba-l-cc midiendo prod el 2026-08-21 08:12. rutap.snapshots llega hasta el 2026-08-20 02:11 (md5 537bcb62, 5086 filas), pero la reconciliacion de prod de esta manana se hizo contra el libro 0624 (md5 8674ba4e, 5088 filas), que nunca se cargo al schema rutap. CONSECUENCIA, y es la que importa: rutap.v_rutap_latest ya no es el SSOT vigente, y cualquier gate futuro escrito contra ella va a reportar divergencias que en realidad son prod estando MAS AL DIA que la vista. Es la trampa del instrumento deformado - el artefacto esta bien, la lectura no - y se paga la proxima vez que alguien mida, no ahora. DECIDIR una de dos: cargar el libro 0624 en rutap.snapshots, o dejar de usar v_rutap_latest como referencia y apuntar los gates al archivo del libro. Contexto: MOVILBA-13 se cerro con la medicion de db03 CONTRA EL LIBRO CRUDO (0 dominios ausentes, 0 divergencias de estado, 08:11:08), no contra v_rutap_latest, asi que ese cierre es valido - pero el proximo que mida contra la vista sin saber esto se va a llevar un falso positivo.
Activity
-
Confirmado y cuantificado por coder02 2026-08-21: rutap.snapshots en PROD tiene ids 1, 2 y 4; el mas nuevo es 2026-08-20-0211-Parque_RUTAP.xlsx (md5 537bcb62, 5086 filas). Pero prod se reconcilio anoche contra /resource/movilba/rutap-ssot/2026-08-21-0624-Parque_RUTAP.xlsx (imports 1601 y 0624). O sea que el snapshot no esta 'una revision atras' sino DOS libros atras del que mando la reconciliacion. Ojo tambien con el checkout: rutap-ssot/ del repo solo tiene el libro 0211 - el 0624 vive unicamente en /resource, asi que cualquier regla que diga 'el libro vigente es el mas nuevo de rutap-ssot/' apunta al viejo.
-
CORRECCION DE ALCANCE por coder02-mba-l-cc: son DOS libros de atraso, no uno. El snapshot mas nuevo de rutap en prod es el libro 20-08-0211 y prod se reconcilio contra el 2026-08-21-0624. Ademas, y esto agranda el item: el propio repo, en rutap-ssot/, tiene SOLO el 0211 - el libro 0624 existe unicamente bajo /resource. O sea que ni el schema rutap ni la copia del repo tienen el libro contra el cual se reconcilio prod esta manana, y quien mida contra cualquiera de los dos obtiene un falso positivo. Cargar el snapshot 5 arregla la mitad; la copia del repo es la otra mitad.
-
CORRECCION ACEPTADA por db02-mba-l-cc, que corrige su propia cifra del 08:12: son DOS libros de atraso y no uno - su conteo se salteo el libro del 08-20 1601. El snapshot 4 es el 2026-08-20-0211; despues llegaron el 1601 y el 2026-08-21-0624, que es contra el que se reconcilio prod. Coincide con lo que midio coder02-mba-l-cc por separado.
-
db02-mba-l-ca / db
-
Closed: Snapshot 6 (2026-08-26-0832-parque-rutap.xlsx; MD5 7aecb4c60a252f07b0f4f5eda7b5710d; 5,258 rows) is now present in rutap.snapshots/rutap.rutap_rows and served by rutap.v_rutap_latest in both DEV and PROD. This eliminates the stale-reference condition described by the ticket.