Espejo Mongo DEV — corte del 23-sep-2026
Qué pasó
La réplica de Mongo desarrollo (DEV), administrada por Juan, dejó de recibir órdenes de Mercado Libre el 23-sep-2026 a las 23:01:47 ART. La última orden registrada es ml-2000015182754249. Es el segundo corte documentado: el anterior fue el 24-ago a las 14:31.
Qué está afectado y qué no
| Qué | Fuente | Afectado |
|---|---|---|
| Ventas del Plant (B2C, B2B, int) | PROD | ❌ No |
| Ventas de ML en el Pulso y el monitor general | KV (API directa) | ❌ No — migrado el 24-ago |
| Ventas de ML en sellers.plantinterno.com | DEV | ✅ SÍ |
| Liquidación del ciclo Planter (parte ML) | DEV | ✅ SÍ |
| Serie de 70 días / 12 ciclos (parte ML) | DEV | ✅ SÍ |
| Top productos ML en Sellers | DEV | ✅ SÍ |
| Stock en Plant / FULL / ajustes / canceladas | PROD/KV | ❌ No |
Impacto cuantificado (al 27-sep):
- Ciclo activo: 20/09 al 19/10 (cierra el 20/10).
- Días del ciclo sin data ML: 4 (24, 25, 26, 27 sep) y contando.
- Órdenes ML faltantes: ~3.200 (basado en ~800/día).
- Las liquidaciones de marcas que venden por ML muestran números congelados al 23/09, sin error visible.
La causa
El endpoint DEV (https://mongoaggregate-ftl2a4nokq-rj.a.run.app/mongoAggregate, Cloud Run en GCP) está vivo y responde consultas. El problema no es el servicio: es el proceso que alimenta la base con las órdenes de ML que dejó de correr. Ese proceso lo administra Juan (el "espejo de Juan") y no hay acceso desde el asistente ni desde plant-interno para reiniciarlo.
La solución inmediata: hablar con Juan
Gabriel tiene que pedirle a Juan que reinicie la réplica/sincronización de órdenes ML en el ambiente de desarrollo de GCP. Históricamente se ha cortado solo y se levanta reiniciando el proceso.
La solución de fondo: migrar sellers a la misma fuente que ya funciona
El monitor general de ventas ML (build_ml.py) ya NO depende del espejo: lee directo de la API de Mercado Libre y guarda en KV mlv:d:<fecha>. Esa fuente tiene datos actualizados al minuto.
Sellers NO hizo esa migración porque necesita el detalle por publicación (MLA ID) para cruzar contra ml:mapa y asignar la venta a cada marca. Sin embargo, el KV sí guarda ese detalle: mlv:d:<fecha>.it tiene hasta 2.500 items con MLA ID, cantidad y neto.
La diferencia semántica: sellers filtra por fecha de envío (shippingDate), no de creación. Para una migración completa hay que:
- Ampliar la fuente de KV para guardar la fecha de envío por publicación, o
- Consultar la API de ML desde
build_sellers.pycon el detalle de shipment, o - Usar fecha de creación como proxy (la diferencia dentro de un ciclo de 30 días es marginal en el total, pero hay bordes de ±2 días que afectan a marcas chicas).
Mi recomendación: la opción 2, que es exactamente lo que ya hace build_ml.py y se puede adaptar al contexto de sellers. El KV pasa a ser el almacén intermedio y la API de ML la fuente de verdad.
Verificación realizada
POST https://mongoaggregate-ftl2a4nokq-rj.a.run.app/mongoAggregate
{"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"}}
]}
→ [{"ts":1790215307,"oid":"ml-2000015182754249"}]
→ 2026-09-23 23:01:47 ART ← última orden en DEV
Confirmado: la API del worker ML sí tiene datos del 24 al 27 sep (KV mlv:d:*), con ~700-850 órdenes/día y detalle por MLA ID.
🔗 Conexiones Neuronales
- Eje: monitores-planter|Monitor Planter · Liquidaciones & Sellers
- Eje: plant-interno-tableros
- Eje: desarrollo-de-capacidades|Desarrollo de Capacidades & Empoderamiento
- Eje: asistente-gaby
Datos/espejo-mongo-dev-corte-23sep