Monitores Planter — origen de datos, 27-sep-2026
<!-- ESTADO-VIVO:INICIO -->
⚡ ÚLTIMO ESTADO VIVO (Actualizado: 2026-10-29 16:48 · Orden Cronológico Inverso: Más Nuevo Arriba)
- Estado: funciona sin problemas
- Estado: ES LA RÉPLICA QUE SE CORTA SOLA. Documentado en
plant-datos-endpoints.md(sección "VENTAS DE ML DIRECTO DE LA API"): «El espejo de Juan (mongoaggregate DEV) se frena solo (24/08 se cortó 14:31)». - Estado: se escribe por otros crons y está actualizado
<!-- ESTADO-VIVO:FIN -->
Resumen ejecutivo
Los monitores de Sellers usan dos fuentes de Mongo y varias claves de KV. La venta por el Plant sale de Mongo PROD (activo); la venta por Mercado Libre sale de Mongo DEV (la réplica de desarrollo). La réplica de desarrollo se corta sola con frecuencia (documentado el 24-ago, cuando se cortó a las 14:31). Si la réplica se cortó el 23-sep, las ventas de ML en los monitores de Sellers están afectadas: muestran datos congelados al momento del corte, no ventas en vivo.
Los tres orígenes de datos
1. Mongo PRODUCCIÓN (PROD) — activo, no afectado
- URL:
https://us-central1-vivet-web.cloudfunctions.net/mongoAggregate - Qué trae: ventas del Plant (canal directo), catálogo de productos, marcas, ajustes de inventario, canceladas
- Funciones:
agg()→ventasPlant(),catalogo(),logos(),ajustesInternos(),canceladasDelPeriodo() - Estado: funciona sin problemas
2. Mongo DESARROLLO (DEV) — potencialmente cortado
- URL:
https://mongoaggregate-ftl2a4nokq-rj.a.run.app/mongoAggregate - Qué trae: ventas de Mercado Libre (las órdenes de ML de producción solo tienen carga manual, la venta real está en DEV)
- Función:
aggDev()→ventasML()(línea 321 de build_sellers.py) - Estado: ES LA RÉPLICA QUE SE CORTA SOLA. Documentado en
plant-datos-endpoints.md(sección "VENTAS DE ML DIRECTO DE LA API"): «El espejo de Juan (mongoaggregate DEV) se frena solo (24/08 se cortó 14:31)». - Impacto si está cortada: las ventas de ML en la liquidación de Sellers se congelan en la última fecha que tenga la réplica. No hay error visible: la consulta devuelve datos, pero son viejos.
3. KV de Cloudflare (namespace ML) — activo, no afectado
- Qué trae: mapas de publicaciones (
ml:mapa,mla2marca), stock FULL (stockmap), logos (sellers:logos), marcas (sellers:marcas), proveedores (sellers:proveedores), reglas de alta/stock inicial (planter:reglas), motivos de ajuste (sellers:motivos) - Estado: se escribe por otros crons y está actualizado
¿Qué números están afectados?
| Sección del monitor | Fuente | Afectada |
|---|---|---|
| Ventas del Plant (canal directo) | PROD | ❌ No |
| Ventas de Mercado Libre | DEV | ✅ SÍ |
| Liquidación del ciclo (total) | PROD + DEV | ✅ SÍ (la parte de ML) |
| Serie de 70 días / 12 ciclos | PROD + DEV | ✅ SÍ (la parte de ML) |
| Stock en el Plant | PROD | ❌ No |
| Stock en FULL de ML | KV (stockmap) | ❌ No |
| Ajustes internos (merma) | PROD | ❌ No |
| Canceladas del período anterior | PROD | ❌ No |
| Top productos (ML) | DEV | ✅ SÍ |
| Logos, marcas, mapas | KV | ❌ No |
La migración que ya se hizo para el monitor general pero NO para Sellers
El monitor general de ventas (build_ml.py) ya migró a leer ventas de ML directo de la API de Mercado Libre, guardadas en KV como mlv:d:<YYYY-MM-DD>. Esa migración se hizo el 24-ago justamente porque la réplica se frenaba sola.
Los monitores de Sellers NO hicieron esa migración. Siguen consultando la réplica DEV con aggDev() porque necesitan el detalle por publicación (para cruzar contra ml:mapa y asignar a marca), y la fuente nueva de KV no tiene ese nivel de detalle por marca que necesita la liquidación.
Cómo verificar si la réplica está cortada ahora
Hacer un POST a https://mongoaggregate-ftl2a4nokq-rj.a.run.app/mongoAggregate con:
{"index": "orders", "aggregate": [
{"$match": {"data.objectID": {"$regex": "^ml-"}}},
{"$sort": {"data.timestamp_timestamp": -1}},
{"$limit": 1},
{"$project": {"_id": 0, "ts": "$data.timestamp_timestamp", "oid": "$data.objectID"}}
]}
Si la fecha de la última orden es anterior al 23-sep, la réplica está cortada y los números de ML en Sellers están congelados.
Qué hacer
Para que los monitores de Sellers no dependan de la réplica, hay que migrar ventasML() a una fuente que no se corte. Dos opciones:
- Ampliar la fuente de KV (
mlv:d:*) para que guarde el detalle por publicación (hoy solo guarda top 300) y leer de ahí en vez de DEV. - Consultar la API de ML directo desde el Worker, igual que hace
build_ml.py, pero con el detalle deitem_idpara poder cruzar contraml:mapa/mla2marca.
Mientras tanto, las ventas del Plant (que son la mayoría de la liquidación) están bien.
🔗 Conexiones Neuronales
- Eje: elevar-conciencia
- Eje: monitores-planter|Monitor Planter · Liquidaciones & Sellers
- Eje: plant-interno-tableros
Datos/sellers-plantinterno-origen-datos-diagnostico-27-sep