varela-bot — bot de Telegram para acuses de recursos materiales

Bot de Telegram (python-telegram-bot v20+, async, webhook) para personal de recursos materiales de Trivasa: avisa que hay que notificar a un cliente que su material está listo, y espera de vuelta la foto del acuse de entrega/recolección. Repo ehalso/varela-bot (privado), corre en Docker en ctunlinux (~/ehalso/varela-bot/docker-compose.yml), publicado en bot.frento.com.mx vía el mismo túnel Cloudflare (0bf84666-...) que el resto de los servicios de ese host.

Documentado el 2026-08-26 al encontrar la ruta bot.frento.com.mx en el ingress de ctunlinux sin ninguna mención previa en esta wiki — servicio real y en uso (contenedor corriendo desde 2026-08-12), no un huérfano.

Arquitectura

Telegram -> bot.frento.com.mx (cloudflared) -> varela-bot:8091 (webhook PTB)
                                                    │
                                                    ├── APScheduler: poller (TRIVASADB -> avisos nuevos)
                                                    ├── APScheduler: checker (vencidos -> cierra o encadena)
                                                    └── varela-bot-postgres (schema notificaciones.avisos)

Dos contenedores (docker-compose.yml): varela-bot (la app) y varela-bot-postgres (postgres:16-alpine, volumen propio varela-bot-pgdata — no es el warehouse trivasa_dw, base dedicada solo para el estado de los avisos).

Poller/checker contra TRIVASADB deshabilitados a propósito

TRIVASADB_HOST/_USER/_PASSWORD vienen vacíos en el .env actual — sin esas variables, main.py no agenda ni el poller ni el checker (confirmado en el log del contenedor: "TRIVASADB_HOST/USER/PASSWORD no configurados -- poller y checker NO se agendan. El bot sólo sirve el webhook de fotos/acuses."). El bot está corriendo en modo reducido: solo recibe y empareja fotos de acuse manualmente, no genera avisos nuevos por su cuenta todavía. bot/trivasadb.py además trae queries placeholder (fetch_folios_listos, folio_sigue_pendiente) sin verificar contra el esquema real de dbo.Folios/EstatusMaterial — pendiente antes de activar esa parte.

Emparejamiento de fotos y dedup

• El poller (cuando esté activo) no crea un aviso nuevo para un folio si ya existe una fila en avisos con status IN ('esperando_acuse', 'acuse_recibido') para ese folio_id — evita duplicar una cadena de aviso activa.
• Fotos de acuse se emparejan por reply directo; si no llega como reply, cae a un fallback con InlineKeyboard para elegir el folio a mano. Requiere privacy mode desactivado en BotFather (/setprivacy → Disable) o el bot como admin del grupo, para poder leer fotos que llegan como reply sin ser comandos.
• Al recibir la foto: status='acuse_recibido', acuse_at=now().

Secretos

TELEGRAM_BOT_TOKEN vive en el .env local del stack (el contenedor lo lee de ahí en runtime) y además tiene copia de resguardo en Infisical — pero en un proyecto propio (secret-management, id b6567423-9986-448e-b2b8-dffe44fe1657, environment dev), no el proyecto general Estebanalcocer.cloud que usa el resto de esta infraestructura (ver Gestión de secretos). El resto de credenciales (Postgres propio, TRIVASADB) también solo en .env, sin respaldo adicional.

Publicación: mismo túnel de ctunlinux

bot.frento.com.mx → http://127.0.0.1:8091 es una regla más del único cloudflared.service de ctunlinux (ver ctunlinux § túnel) — mismo patrón que Metabase/Perses/Lightdash/Glances en ese host. PTB sirve el webhook en HTTP plano; el TLS lo termina el túnel, no el contenedor.

Véase también

• ctunlinux — el host y el túnel que publica bot.frento.com.mx
• Wasquedul — otro bot de Telegram de Esteban (recordatorios de WhatsApp), en vm-main — patrón similar (long polling/webhook + LLM/lógica propia) pero proyecto y cuenta de Telegram distintos
• Gestión de secretos — por qué TELEGRAM_BOT_TOKEN vive en un proyecto Infisical separado del resto
• Túneles de Cloudflare — catálogo de túneles, pendiente de sumar bot.frento.com.mx a la tabla de ctunlinux