Plan del worker asíncrono entrante de Discord

Objetivo

Eliminar el timeout del listener de Discord como modo de fallo visible para el usuario haciendo que los turnos entrantes de Discord sean asíncronos:

1. El listener del gateway acepta y normaliza los eventos entrantes rápidamente.
2. Una cola de ejecución de Discord almacena trabajos serializados indexados por el mismo límite de ordenamiento que usamos hoy.
3. Un worker ejecuta el turno real del agente fuera del tiempo de vida del listener de Carbon.
4. Las respuestas se entregan al canal o hilo de origen después de que la ejecución se completa.

Esta es la solución a largo plazo para las ejecuciones de Discord encoladas que agotan el timeout en channels.discord.eventQueue.listenerTimeout mientras la ejecución del agente todavía está progresando.

Estado actual

Este plan está parcialmente implementado.

Ya realizado:

• El timeout del listener de Discord y el timeout de ejecución de Discord ahora son configuraciones separadas.
• Los turnos entrantes de Discord aceptados se encolan en src/discord/monitor/inbound-worker.ts.
• El worker ahora posee el turno de larga duración en lugar del listener de Carbon.
• El ordenamiento existente por ruta se preserva por clave de cola.
• Existe cobertura de regresión de timeout para la ruta del worker de Discord.

Lo que todavía falta:

• DiscordInboundJob todavía está solo parcialmente normalizado y aún lleva referencias de runtime en vivo
• La semántica de comandos (stop, new, reset, futuros controles de sesión) aún no es totalmente nativa del worker
• La observabilidad del worker y el estado del operador aún son mínimos
• Todavía no hay durabilidad ante reinicios

Arquitectura objetivo

1. Etapa del listener

DiscordMessageListener sigue siendo el punto de ingreso, pero su trabajo se reduce a:

• Ejecutar verificaciones de preflight y políticas
• Normalizar la entrada aceptada en un DiscordInboundJob serializable
• Encolar el trabajo en una cola asíncrona por sesión o por canal
• Retornar inmediatamente a Carbon una vez que el encolamiento tiene éxito

2. Payload normalizado del trabajo

Introducir un descriptor de trabajo serializable que contenga solo los datos necesarios para ejecutar el turno después.

3. Etapa del worker

Agregar un ejecutor de worker específico de Discord responsable de:

• Reconstruir el contexto del turno desde DiscordInboundJob
• Cargar media y cualquier metadato de canal adicional necesario para la ejecución
• Despachar el turno del agente
• Entregar los payloads de respuesta finales
• Actualizar estado y diagnósticos

4. Modelo de ordenamiento

El ordenamiento debe permanecer equivalente al de hoy para un límite de ruta dado.

5. Modelo de timeout

Después de la transición, hay dos clases separadas de timeout:

• Timeout del listener: solo cubre normalización y encolamiento; debe ser corto
• Timeout de ejecución: opcional, propiedad del worker, explícito y visible para el usuario

Criterios de aceptación

El plan se completa cuando:

1. El timeout del listener de Discord ya no aborta turnos largos saludables.
2. El tiempo de vida del listener y el tiempo de vida del turno del agente son conceptos separados en el código.
3. Se preserva el ordenamiento existente por sesión.
4. Los canales de Discord vinculados a ACP funcionan a través de la misma ruta del worker.
5. stop apunta a la ejecución propiedad del worker en lugar de la pila de llamadas del listener antiguo.
6. Los fallos de timeout y entrega se convierten en resultados explícitos del worker, no en drops silenciosos del listener.