Validación — Scheduler, batch y colas
Uso interno. No exponer como material para stakeholders.
Estado
- Última actualización: 2026-08-02
- Owner: Desarrollo / documentación
Confirmado en código
La versión anterior de la documentación marcaba el scheduler como "pendiente de confirmar existencia". Existe y está definido en el código, con 9 tareas programadas en zona horaria America/Mexico_City. Ver Scheduler y batch.
Hallazgos relevantes:
- El cron del servidor ejecuta
schedule:runcada minuto para cada instancia de participante. Una sola entrada de cron gobierna todas las tareas. ecd:synctrabaja con 5 días de desfase, no con el día anterior.- La cadena diaria corre entre las 05:00 y las 08:30, con tiempos fijos entre etapas.
bot:queue --slug=bank-onees la única tarea semanal (lunes 07:00).- El repositorio declara más de 45 comandos propios, de los cuales solo 9 están programados. El resto se ejecuta a mano.
Gaps abiertos
| Gap | Detalle | Quién lo cierra |
|---|---|---|
| Idempotencia | Sin confirmar por comando. Es el dato que decide si se puede reintentar. Máxima prioridad. | Desarrollo |
| Alertamiento | No hay alerta cuando una tarea no corre, cuando el cron cae o cuando un worker muere. | Infraestructura |
| Tiempos reales | Los márgenes entre etapas son fijos y no medidos. No hay criterio para decidir que una etapa "se tardó". | Infraestructura |
Log de bank-one | La tarea semanal no escribe log dedicado; no se puede verificar si corrió. | Desarrollo |
| DLQ | No está documentado si existen colas de mensajes muertos ni su tratamiento. | Desarrollo |
| Paridad entre instancias | Falta confirmar que el scheduler corre con los mismos horarios en todos los participantes. | DevOps |
| Descripciones por omisión | Varios comandos conservan Command description: ecd:upload_invoices_to_s3, passthrough:check-cenace-energy, service:demand-sync, sync:prices. Su propósito se dedujo del código. | Desarrollo |
Riesgos identificados
- Falla silenciosa del cron. Si se detiene, ninguna tarea corre y no se genera ningún error: los logs quedan vacíos. Es el modo de falla más difícil de notar.
- Falla silenciosa de workers. Los comandos que despachan reportan éxito sin que nada se procese.
- Efecto multiplicador de
--ending_at. Los comandos de despacho recorren día por día; sin--rmumultiplican por el número de centros de carga. Un solo comando puede encolar miles de trabajos. remove:pricesborra sin confirmación. No tiene modo de simulación ni confirmación interactiva.demo:sanitizeen producción. Está bloqueado y exige sufijo_demoen el nombre de la base. El bloqueo es deliberado y no debe removerse.