Incidente 2026-09-19 — Precio de cache incorrecto en Autocobro

1. Resumen

• Reclamo de Dino el 19/09/2026: el autocobro mostró $1.05 en lugar de $8490.00 para el EAN 2500176000005, sucursal 1 (QUESO CREMOSO SAINT PAULIN TROZ X KG, código interno 3500176).
• Reiniciar TsArticulos "arregló" el problema — pero solo durante 4 horas.
• No es un refresh de cache fallido ni omitido. El refresh de precarga funcionó correctamente durante todo el incidente.
• La causa es una divergencia entre dos caminos de resolución de cache que leen filas duplicadas en dm_artic en orden distinto.
• El vencimiento de la cache a las 4 horas (expireAfterWrite) es lo que alterna el tráfico entre el camino correcto y el incorrecto.
• El 1.05 fue un precio real publicado por la política de precios del cliente el 18/09 a las 11:03 y corregido 16 minutos después; el defecto es que TsArticulos lo resucitó un día entero más tarde a través del camino on-miss.
• El incidente terminó recién con el completo de datos del 20/09 a las 21:44, que reconstruyó dm_artic y eliminó la fila superada; los reinicios manuales del 19/09 solo daban alivio temporal (~4 horas cada uno).

2. ¿Fue un bug o un precio mal actualizado? — Cadena causal

El incidente combina cuatro eslabones independientes; solo uno de ellos es un defecto de software. La tabla resume qué pasó, con qué evidencia, quién es responsable, y si constituye un bug de TsArticulos.

3. Ranking de causas

1. (Causa raíz, único defecto) On-miss de TsArticulos no aplica el contrato "vigente = mayor iVersion" — corregido en la rama fix/duplicate-tiebreak-sql-it (ver sección 8, F1).
2. (Disparador) Expiración de cache a 4 h + refresh disparado solo por novedades + scheduler de Dino una vez por día → en días sin novedades, todo cae a on-miss desde ~11:00. Mitigación: cron cada 30 min (F0).
3. (Ventana de exposición, no un defecto) Tabla multi-versión por diseño + sin completos viernes y sábado por política del cliente → la versión superada vivió 58 horas en dm_artic.
4. (Origen del valor, no un defecto de sistemas) Precio 1.05 publicado por el cliente durante 16 minutos el 18/09.

Causas descartadas (evaluadas y refutadas por la evidencia):

• Reinserción / reprocesamiento de novedades tras la caída de SQL Server de las 16:53 — refutada por el código fuente de SrvPOS_Artic_Novedades.cpp: no existe lógica de replay (la escritura y el marcado "procesado" comparten una sola transacción; si aborta, la corrida siguiente repite limpio).
• Refresh fallido, colgado u omitido — todos los refresh del 19–20/09 finalizaron OK.
• Filtro de cache sin discriminar sucursal — descartado (ver sección 5, "¿Pudo ser un filtro que no discrimina sucursal?").
• Precio no actualizado por el cliente — descartado: todas las novedades desde la 29281 y el completo 30620 traen 8490.00.

4. Reclamo de origen (ticket)

Ticket a cargo de sprados / jsalvini. Última modificación: 21/09/2026 10:19:11 por lbevolo.

Reclamo del cliente (19/09, Dino, contacto Eduardo)

Solo para que puedan ver el lunes este problema que surgió este finde. Hubo un cambio de precio de un producto en el cual no impacto en las cajas de autocobros. Luego de consultar con tipre, nos sugirió que reiniciemos el servicio TsArticulos, en el cual luego de unos minutos se probro en las pantallas y ya pasaba sin problemas. [...] Antes de reiniciar el servicio salía a 1.05 , al reiniciar empezó a salir 8490 pesos.

Adjunto del ticket: Autocompra_ReclamoDino20260919.png.

Respuesta del equipo (19 y 21/09)

Se informó que la actualización de cache para Autocompra a partir de novedades y completos ya estaba habilitada; el reinicio se sugirió por falta de acceso remoto en el momento del reclamo.

Nota del ticket: refresh observado OK post novedad

Log del proceso de novedades (sender) del 18/09 11:03:54:

[REFRESH][ARTIC] POST 172.17.11.210:48082/articulos/v1/cache/refresh -> HTTP 202 {"success":true,...,"status":"STARTED","refreshId":"e8de4533-a7bc-4e6a-ac0f-3888e71682f8"}
[REFRESH][PROMO] POST 172.17.11.210:48085/promos/v1/promociones/update -> HTTP 202

(Un primer log pegado en el ticket, fechado 28/08, fue corregido por el autor del ticket por este del 18/09.)

5. Análisis efectuado

Fuentes analizadas

Método

1. Lectura del camino de refresh (POST /cache/refresh → startRefresh → executor asíncrono → buildAndSwapCache). Hallazgo: el HTTP 202 se devuelve también para SKIPPED_ALREADY_RUNNING; el log del sender no prueba finalización.
2. Hipótesis iniciales, rankeadas:
   • H1 — refresh colgado deja refreshRunning=true y todos los siguientes se omiten.
   • H2 — refresh iniciado pero fallido a mitad de carga.
   • H3 — novedad llegada durante un refresh en curso → solicitud descartada.
   • H4 — filas duplicadas cean|inrosuc en dm_artic.
3. Contraste con logs del servicio: patrones buscados >>> Inicio refresh, Refresh de cache finalizado|fallido, Cache activa actualizada, ERROR. Resultado: todos los refresh del 19–20/09 finalizaron OK (2–3 s, 84058 artículos), ningún fallido, ningún skip → H1, H2 y H3 descartadas. Único ERROR relevante: 18/09 16:53:51, arranque fallido por SQL Server no disponible (localhost:1433 connection refused), recuperado a las 16:54:39. El análisis posterior del código fuente de SrvPOS (sección 3, Ranking de causas) descartó que este evento explicara las filas duplicadas — no existe lógica de reprocesamiento en el proceso de novedades.
4. Búsqueda del síntoma: precioTotal=1.05 → 19 respuestas el 19/09 y 6 el 20/09, todas para el EAN 2500176000005 sucursal 1.
5. Línea de tiempo completa del EAN en los 5 archivos: dos id distintos para el mismo EAN (826360887 → 1.05; 826361083 → 8490.00) y correlación exacta de cada respuesta 1.05 con un Producto agregado a cache previo (camino on-miss) → H4 confirmada.
6. Explicación de los miss: expireAfterWrite(4h) en CacheConfig; el primer 1.05 aparece a las 11:09, 4h09 después del preload de 07:00; tras el reinicio de 15:54 vuelve el 1.05 a las 20:59.
7. Hallazgo colateral: no se recibió ningún POST /cache/refresh entre el 18/09 17:13:49 y el 20/09 21:40:22.

6. Causa raíz

La tabla dm_artic tiene dos filas para el mismo cean + inrosuc: el id 826360887 con precio 1.05 (iVersion 28771) y el id 826361083 con precio 8490.00 (iVersion 29365). Dos caminos distintos del código resuelven esta ambigüedad de forma diferente, y solo uno de ellos es determinista.

Esto no es un accidente aislado: por diseño del proceso de novedades (SrvPOS_Artic_Novedades.cpp), cada ciclo borra e inserta en dm_artic todas las filas PRODUCTO WHERE COMPLETO=0 pendientes desde el último completo, sin deduplicar por EAN y en orden AUTOINC (línea 1290) — por eso dm_artic es una tabla multi-versión mientras no llega un completo, y por eso el orden de iid coincide con el de iVersion (ambos derivan del mismo AUTOINC). Un completo (DELETE FROM dM_Artic + reinserción del snapshot, líneas 962–979) es lo único que limpia las versiones superadas; no se generó ninguno el 18/09 ni el 19/09 por política del cliente, así que la fila v28771 (1.05) convivió con la v29365 (8490.00) hasta el completo del 20/09 21:44 (ver sección 7, Evidencia).

El precio 1.05 no fue un error de TsArticulos: fue un precio real publicado por el cliente el 18/09 a las 11:03 y corregido 16 minutos más tarde (ver "Origen del precio 1.05" en la sección 7). El defecto de TsArticulos es que el camino on-miss no respeta el contrato implícito de dm_artic ("la fila vigente es la de mayor iVersion") y resucitó la fila superada un día después, en vez de resolver el duplicado con el mismo criterio que la precarga.

Precarga: consulta ordenada, resultado determinista

• La consulta de precarga (ArticulosCacheLoadRepositoryImpl) ordena ORDER BY dm.inrosuc, dm.iid.
• ArticuloCacheService.loadSucursalInCache hace targetCache.put(key, row) fila por fila; la última escritura pisa a las anteriores.
• Con orden ascendente por iid, el id mayor (826361083, 8490.00) siempre queda al final y gana.

On-miss: consulta sin orden, resultado arbitrario

• ArticuloCacheService.getArticuloByEanAndSucursal (línea ~74) llama a articulosRepository.findByEanSuc(ean, sucursal).stream().findFirst().
• La consulta nativa de ArticulosRepository.findByEanSuc no tiene ORDER BY; SQL Server es libre de devolver cualquiera de las dos filas primero.
• En producción devolvió el id 826360887 (1.05).

El vencimiento decide qué camino gana

• CacheConfig (línea 20): Caffeine.newBuilder().expireAfterWrite(4, TimeUnit.HOURS).
• 4 horas después de cualquier put() —precarga u on-miss— la entrada expira.
• Mientras vive la entrada de precarga, el precio es correcto. Al expirar, el siguiente pedido cae en on-miss y el precio pasa a ser el incorrecto hasta el próximo evento que reescriba la entrada.

7. Evidencia (logs 19–20/09)

La línea de tiempo reconstruida a partir de logs/tsarticulos.log.2026-09-19.0 y logs/tsarticulos.log.2026-09-20.0 muestra cómo el reinicio manual del 19/09 solo desplazó el problema 4 horas, en lugar de resolverlo.

Días previos: siempre el precio correcto

• 17/09 10:05, 18/09 17:01 y 17:48: siempre responde 8490.00.
• El 18/09 los refresh de novedades (POST /cache/refresh, trigger MANUAL) llegaban cada ~5 minutos.
• Los refresh frecuentes reescriben la cache antes de que las entradas lleguen a expirar, por lo que enmascaran el bug.

Factor agravante: fin de semana sin novedades (no es una falla del emisor)

• No se recibió ningún POST /cache/refresh entre el 18/09 17:13:49 y el 20/09 21:40:22 porque no hubo novedades en ese lapso: la última dX_Artic fue la versión 30611 a las 18/09 17:13; el siguiente artefacto es recién el completo dM_Artic.30620 del 20/09 21:44.
• El refresh de cache está disparado por la llegada de novedades (trigger MANUAL), no por un scheduler propio del emisor; sin novedades no hay refresh — esto no es una falla ni del emisor ni del receptor.
• En Dino el scheduler propio de TsArticulos corre una sola vez por día (~07:00). En un día sin novedades, todas las entradas de la cache expiran 4 horas después de ese preload (~11:00) y, de ahí en más, todos los lookups caen en on-miss.
• Eventos "Producto agregado a cache" (on-miss) por día: 17/09 = 424, 19/09 = 1710, 20/09 = 2492.

Novedades hace INSERT, no UPDATE — los duplicados se acumulan hasta el próximo completo

• El total de artículos precargados crece con cada refresh disparado por novedades: 17/09 13:12 → 83939 ... 18/09 16:38 → 84028, 17:03 → 84038, 17:08 → 84049, 17:13 → 84058.
• El 20/09 21:44:21, tras el "completo", el total cae a 84011: las filas se regeneraron entre las 21:40 y las 21:56 con nuevos iid; la fila de sucursal 1 de este EAN pasó a ser id 826533626, fPrecio neto 7016.5289 (8490.00 final), iVersion 30620.
• En consecuencia, las filas duplicadas cean|inrosuc se acumulan entre completos (~47 al momento del incidente) y desaparecen con cada completo. No se generó ningún completo el 18/09 ni el 19/09 por noche por política del cliente (no hay lógica de día de la semana en SrvPOS: un completo depende únicamente de que el origen publique filas con COMPLETO=1).
• Las filas duplicadas del incidente (18–20/09, ids 826360887 y 826361083) ya no existen en la tabla: fueron reemplazadas por el completo del 20/09 a la noche.

Impacto en Autocompra

25 consultas de Autocompra recibieron el precio erróneo (1.05): 19 el 19/09 entre las 11:09 y las 21:04, y 6 el 20/09 entre las 12:37 y las 20:55. Corresponden a 16 etiquetas de peso distintas, ≈ 21.1 kg pesados (33.7 kg contando re-escaneos de la misma etiqueta). El peso se decodificó de la etiqueta de pesada 25 00176 WWWWW C (gramos).

Exposición máxima estimada ≈ $179.000 (21.1 kg × 8488.95, la diferencia de precio por kg entre 8490.00 y 1.05). Es una cota superior: una consulta de Autocompra no implica una venta concretada; para una cifra real hay que cruzar estos escaneos con los tickets efectivamente emitidos por Autocompra.

Origen del precio 1.05: novedad dX_Artic 28771 (archivos Btrieve)

Se decodificaron directamente los archivos Btrieve de las novedades (Docs/zip/dX_Artic.<versión>.zip) para el EAN 2500176000005: registro con cEan en el offset 0, iArticulo en +14, descripción en +21 y precio como double IEEE-754 little-endian en +49 (bytes CD CC CC CC CC CC F0 3F = 1.05).

• El número de versión del zip coincide exactamente con iVersion en dm_artic: la fila 1.05 servida por TsArticulos tenía iVersion 28771 — coincidencia exacta con la novedad que introdujo el precio erróneo. La fila 8490.00 tenía iVersion 29365.
• El log del sender citado en el ticket (18/09 11:03:52–11:03:54, "dX_Artic ... cant. registros iguales (16)" seguido de POST /cache/refresh) es exactamente la generación de la novedad 28771.
• La tabla de ventas confirma que el precio erróneo estuvo vivo en las cajas normales (POS) el 18/09: tres tickets para este EAN con precio unitario 1.48 / 1.11 / 1.01 (artículo pesado a 1.05/kg), uno con descripción "QSO.SAINT.PAU KG 1.05".

8. Fix propuesto Propuesto — pendiente de aprobación

La regla elegida para la propuesta es la opción B: mayor iVersion, luego mayor iid, aplicada en ambos caminos (on-miss y precarga) — ver el callout "El contrato de versionado de dm_artic" debajo. Ningún cambio de código fue aprobado ni aplicado en main. El detalle técnico de cada cambio propuesto (archivo, línea, snippet, pruebas requeridas, riesgo) está en el Anexo A.

SELECT cean, inrosuc, COUNT(*) c FROM dm_artic WITH(NOLOCK) GROUP BY cean, inrosuc HAVING COUNT(*) > 1

Tradeoffs considerados

• Quitar expireAfterWrite ocultaría el síntoma (el precio incorrecto tardaría más en aparecer) pero no corrige la divergencia entre los dos caminos.
• F1 es el cambio más chico que hace consistentes ambos caminos: mismo criterio de desempate en precarga y en on-miss.
• F0 (cron cada 30 min) es una mitigación operativa, no un fix: reduce la ventana de exposición pero no elimina la causa raíz mientras F1 no esté desplegado en Dino.

9. Verificación

1. Ejecutar el SQL de diagnóstico de duplicados (F4) para confirmar el alcance del problema en dm_artic.
2. Ejecutar la suite de tests, incluyendo el test de regresión de F2 (debe fallar antes de F1 y pasar después).
3. Después del deploy, buscar en el log el EAN 2500176000005 más de 4 horas después de la última precarga y confirmar que responde con id=826361083 / 8490.00.

10. Archivos involucrados

11. Anexo A — Fixes propuestos a nivel de código

Listado ordenado por prioridad (P0 = más urgente). Cada ítem indica archivo:línea, problema, cambio propuesto (con snippet antes/después cuando corresponde), pruebas requeridas y riesgo del cambio. Ningún ítem de este anexo fue aprobado ni aplicado en main; A1–A3 tienen un prototipo de referencia sin commitear en la rama local fix/duplicate-tiebreak-sql-it (ver sección 8).

" WHERE dm.inrosuc = :nrosuc AND dm.cean = :ean "

" WHERE dm.inrosuc = :nrosuc AND dm.cean = :ean " +
" ORDER BY dm.iVersion DESC, dm.iid DESC, env.iVersion DESC, env.iid DESC "

ArticuloProjection current = targetCache.getIfPresent(cacheKey);
if (current == null || isHigherPriority(candidate, current)) {
    targetCache.put(cacheKey, candidate);
}

private static boolean isHigherPriority(ArticuloProjection candidate, ArticuloProjection current) {
    int c = compareNullableVersion(candidate.getIversion(), current.getIversion()); // null = lowest
    return c != 0 ? c > 0 : candidate.getIid() > current.getIid();
}

Infraestructura de pruebas propuesta (acompaña A1–A4, A9)

Perfil Maven integration-sql (failsafe, *IT.java, SQL Server local, base descartable TsArticulosIT, credenciales solo por variables de entorno, se omiten si faltan) y perfil pit (mutation testing sobre ArticuloDto, EnvaseDto, ArticuloService, ArticuloCacheService).

PIT se corrió y verificó el 21/09 contra la rama prototipo (solo tests unitarios, mutadores STRONGER, 43 s): 248 mutantes, 166 detectados = 67 % (cobertura de líneas 87 %, test strength 71 %).

Mutantes sobrevivientes relevantes en el camino monetario (ArticuloDto):

• Condicional en calcularValoresMonetarios.
• En applyMonetaryValues se puede eliminar EnvaseDto.setImpInterno y EnvaseDto.setAlicImpInterno sin que falle ninguna prueba — el impuesto interno del envase queda sin cobertura efectiva.
• Guardas de calcularAlicImpInternoDesdeMonto y defaultValue.
• 5 condicionales del constructor.

mvn -o test-compile org.pitest:pitest-maven:mutationCoverage -Ppit

Reportes HTML en target/pit-reports/.

Orden sugerido de aplicación

1. A7-config (inmediato, sin deploy).
2. A1 + A2 + A3 (un solo cambio, con sus pruebas).
3. A4.
4. A5 + A6.
5. Resto (A8–A14, por prioridad).