chasis_nro partido por un salto de linea en 4 filas de RUTAP (2 de ellas vigentes) - rompe el join por chasis en silencio
Medido por coder-mba-l-cc 2026-08-20 leyendo el sqlite del SSOT directamente. En los 3 snapshots (1, 2 y 4) hay exactamente 4 filas con un salto de linea EMBEBIDO en chasis_nro: fila_excel 1353 AG196RL, 1374 AG732SW, 1406 AG771OC, 1440 AG806JI, todas del mismo lote, todas con la forma 8AB368185P + \n + el resto. DOS de las 4 son filas VIGENTES (fecha_baja NULL): AG732SW y AG771OC. Ninguna otra columna esta afectada: 0 saltos de linea en nro_dominio, expte_alta, expte_baja, linea, fecha_alta, fecha_baja. POR QUE IMPORTA: un salto de linea a mitad de valor rompe la igualdad en silencio, asi que esas 2 filas vigentes NO pueden joinear con prod por chasis. Toda conclusion chasis-keyed de la noche del 20/08 asumio que el string esta limpio, y el cross-check por chasis que coder02 acaba de agregar a pass 0 depende exactamente de ese join. Esta en el libro desde el 2026-08-13 y sobrevivio 3 importaciones. ACCIONES: (1) extender el scan de contaminacion del importador a saltos de linea y CR en chasis_nro, reportando por clase - DETECTA Y REPORTA, nunca auto-corrige; (2) que el cross-check por chasis normalice igual de los dos lados o falla abierto en estas 2; (3) confirmar si pass 0 venia contando estas 4 como no-matcheantes desde el principio. Ya reportado a Eugenia en el tracker (Sheet1 fila 30). Emparenta con MOVILBA-40 (el scan cubre solo NBSP, 1 de 5 clases) - esta es la prueba de que esa deuda cuesta algo real.
Activity
-
AMPLIADO por medicion de coder02-mba-l-cc sobre el XLSX del 2026-08-20 (no sobre el sqlite): el salto de linea NO es solo chasis. Chasis_Nro 4 celdas (filas 1353, 1374, 1406, 1440), Motor Nro 6 celdas (1353, 1354, 1374, 1406, 1440, 1441), expediente 8 celdas (386, 461, 462, 472, 2980, 2981, 4023, 4024). Mi medicion previa dijo '0 saltos de linea fuera de chasis' pero fue sobre el sqlite de snapshots, no sobre el xlsx - HAY QUE RESOLVER esa divergencia: o el importador normaliza al cargar (y entonces el sqlite no sirve para medir contaminacion de origen) o los archivos difieren. Bloquea la confianza en cualquier scan hecho contra el sqlite, incluido MOVILBA-40.
-
CORRECCION de mi medicion: '0 saltos de linea fuera de chasis_nro' era falso incluso contra el sqlite - motor_nro tiene 6 y son visibles ahi. El error fue de columna, no de fuente.
-
ALCANCE DEMASIADO ESTRECHO - la contaminacion NO esta solo en Chasis_Nro y Motor Nro (coder02, lectura RAW del xlsx, 06:23). Medido sobre el libro 2026-08-20-0211: Expte. Alta (4359 celdas de texto): 963 con DOBLE ESPACIO interior, 49 NBSP, 46 whitespace de borde, 3 newline. Expte. Baja (3268 celdas): 888 doble espacio, 94 NBSP, 96 borde, 5 newline. Nro_dominio (5086 celdas): 29 con whitespace de borde -- ES LA CLAVE DEL JOIN, p.ej. fila 715 'PIK914 '. Fecha_Alta y Fecha_Baja: CERO celdas de texto, son datetimes reales, limpias, no implicadas. LA CLASE QUE NUNCA MEDIMOS Y ES LA QUE MAS DUELE: el doble espacio esta EN EL MEDIO del valor ('EX-2025-42506664- -GCABA-DGGSM'), asi que strip() no lo toca y TODOS los escaneos de contaminacion de borde que corrimos en la noche lo reportan LIMPIO. Es invisible para cualquier chequeo basado en trim y fatal para un join por igualdad. Las tres clases de borde juntas son ~150 celdas; el whitespace interior son 1851 entre ambas columnas y es el grueso del problema. CONSECUENCIA MEDIDA: filas con Nro_dominio O Expte. Alta contaminado = 1040 de 5086 (expte_alta 1011, dominio 29), contra las 1045 filas que db03 reporto como 'en el libro y no en prod'. Cinco de diferencia a esa escala no es casualidad: el residuo es una FALLA DE PAREO, no una ausencia. NO planificar INSERT. POBLACION DISTINTA, no sumar a las 1040: 727 filas tienen Expte. Alta VACIO -- no tienen clave de pareo y no matchean por ninguna normalizacion. NORMALIZACION QUE SIRVE: sacar todo lo no-alfanumerico de ambos lados (recupero 5 expedientes que un guion escondia). Colapsar corridas de whitespace NO alcanza: NBSP y newline sobreviven.
-
--reason