Cómo Resolver Errores de Multimedia en Webhooks de Telegram con n8n

Cómo Resolver Errores de Multimedia en Webhooks de Telegram con n8n

El Misterio de los Bots Selectivos

Imagina esta situación: tienes tres bots de Telegram corriendo en producción. Los usuarios envían mensajes de audio. Uno de los bots responde perfectamente, transcribe el audio y genera respuestas inteligentes. Los otros dos... simplemente ignoran los mensajes o responden "No veo ningún archivo de mensaje de voz".

¿Suena familiar? Esta fue la situación exacta que enfrentamos con nuestros workflows de automatización. Lo interesante: los tres bots usaban exactamente el mismo servidor, el mismo código base y la misma infraestructura. El problema estaba oculto en dos líneas de código.

Anatomía del Problema

Nuestra arquitectura era limpia: un servidor FastAPI recibiendo webhooks de Telegram, procesando mensajes y ejecutando tareas en segundo plano. Tres endpoints diferentes para tres bots distintos:

• Bot A (@MyCEOIaBot): Funcionaba perfectamente con audio, imágenes y texto
• Bot B (@LaGuapaPrestamosbot): Solo respondía a texto
• Bot C (@GRCotizadorbot): Solo respondía a texto

El código para los tres era prácticamente idéntico. O eso pensábamos.

La Pista Estaba en el Background Task

Al revisar el código del servidor (`main.py`), encontramos algo revelador:

Bot A (funcionaba)
background_tasks.add_task(
process_and_send,
"av0004",
int(chat_id),
prompt,
token,
file_base64,  # ← Aquí está la diferencia
file_name     # ← Y aquí
)
Bot B y C (NO funcionaban)
background_tasks.add_task(
process_and_send,
"er0002",
int(chat_id),
prompt,
token
# ❌ Faltaban file_base64 y file_name
)

Los tres endpoints extraían correctamente `file_base64` y `file_name` del request de Telegram. El problema era que dos de ellos no pasaban estos parámetros a la función que procesaba el mensaje.

La Solución: Dos Parámetros, Tres Bots Arreglados

Paso 1: Backup Obligatorio

Antes de tocar código en producción, siempre:

cp main.py main.py.backup_$(date +%Y%m%d_%H%M%S)

Este simple paso te salva de desastres. En este caso: `main.py.backup_20260111_083345`.

Paso 2: Corrección con sed

Para cambios quirúrgicos en producción, `sed` es tu amigo:

Corregir Bot B (línea 1614)
sed -i 's/background_tasks.add_task(process_and_send, "er0002", int(chat_id), prompt, token)/background_tasks.add_task(process_and_send, "er0002", int(chat_id), prompt, token, file_base64, file_name)/g' main.py
Corregir Bot C (línea 1585)
sed -i 's/background_tasks.add_task(process_and_send, "gr0002", int(chat_id), prompt, token)/background_tasks.add_task(process_and_send, "gr0002", int(chat_id), prompt, token, file_base64, file_name)/g' main.py

Paso 3: Reiniciar el Servicio

sudo systemctl restart deploy-api

Y... ¡funcionó! Pero había un problema más.

El Segundo Problema: Workflows "Activos" Que No Lo Estaban

Bot C tenía otro issue. En la base de datos PostgreSQL de n8n, el campo `active` estaba en `true`, pero el workflow no ejecutaba. ¿Por qué?

Resulta que modificar directamente la base de datos no crea una `activeVersion`. n8n necesita que el workflow se active a través de su API para generar esta versión.

La Solución Correcta

N8N_API_KEY="tu_api_key_aqui"
Primero desactivar
curl -X POST "https://n8n.varelainsights.com/api/v1/workflows/0mfzPhB5v6kKGX2y/deactivate" \
-H "X-N8N-API-KEY: $N8N_API_KEY"
Luego activar (esto crea activeVersion)
curl -X POST "https://n8n.varelainsights.com/api/v1/workflows/0mfzPhB5v6kKGX2y/activate" \
-H "X-N8N-API-KEY: $N8N_API_KEY"

Este proceso garantiza que n8n registre correctamente la versión activa del workflow.

Lecciones Aprendidas

1. La Consistencia es Clave

Si tienes múltiples endpoints con lógica similar, usa funciones compartidas o templates. En este caso, los tres endpoints debieron generarse desde el mismo código base.

2. Los ORMs No Son Magia

Modificar directamente la base de datos de aplicaciones complejas (como n8n) puede romper estados internos. Usa siempre las APIs oficiales cuando estén disponibles.

3. El Debugging es Comparativo

La pista más valiosa fue comparar el endpoint que funcionaba contra los que fallaban. Cuando tienes código "casi idéntico", las diferencias pequeñas son críticas.

Resultado Final

Después de estos cambios:

| Bot | Webhook | Audio | Imágenes |

|-----|---------|-------|----------|

| Bot A | ✅ | ✅ | ✅ |

| Bot B | ✅ | ✅ | ✅ |

| Bot C | ✅ | ✅ | ✅ |

Los tres bots ahora procesan correctamente mensajes de texto, audio e imágenes. Los usuarios pueden enviar notas de voz que se transcriben automáticamente, imágenes que se analizan con IA, y reciben respuestas contextuales.

Conclusión

Este caso demuestra que los bugs más frustrantes suelen ser los más simples: dos parámetros faltantes en una llamada a función. La clave para resolverlos está en:

1. Comparar lo que funciona con lo que no (análisis diferencial)
2. Usar backups antes de cambiar código en producción
3. Respetar las APIs oficiales en lugar de modificar bases de datos directamente

Si estás construyendo bots de Telegram con n8n y FastAPI, revisa que tus background tasks reciban todos los parámetros necesarios, especialmente `file_base64` y `file_name` para multimedia. Tu yo futuro te lo agradecerá.

---