Los canales Direct Line y Chat en web transmiten de nuevo estos errores al software cliente con errores HTTP 502 y 504

@Anshika Varshney
Buen día. Respondemos las tres preguntas. Toda la información se refiere a un único bot, para evitar ambigüedad.

Bot en cuestión:

Recurso Azure Bot: Microsoft.AzureBot group Laboratorio-Bot

App ID (Client ID): 9e1d474f-c797-***********

Tenant ID: a972e859-2d0c-4662-*********

Tipo de app: SingleTenant

Messaging endpoint: https://teams-adapter.staging.aitops.ai/api/messages (público, alcanzable server-to-server)

Canal de Teams: habilitado como "Microsoft Teams Commercial", sin errores en el portal

1. ¿El problema ocurre de forma constante o intermitente?

Constante y 100% reproducible. No es intermitente y no hay casos de éxito parcial: ninguna actividad enviada desde Microsoft Teams ha llegado jamás a nuestro messaging endpoint. Lo probamos con @mención en un canal de equipo y también con chat personal 1:1, en múltiples ventanas a lo largo de varios días (del 27 al 30 de julio de 2026). En todos los casos el resultado fue idéntico: cero entregas. El bot aparece correctamente en Teams, la app se instala y se puede @mencionar con autocompletado, pero el mensaje nunca llega al endpoint.

2. ¿Qué plataforma están utilizando para implementar el bot (Bot Framework SDK o Copilot Studio)?

Ninguna de las dos: usamos el Microsoft 365 Agents SDK (paquete @microsoft/agents-hosting versión 1.7.1, en Node.js), que es el sucesor oficial y GA del Bot Framework SDK — este último fue archivado y su soporte terminó el 31 de diciembre de 2025, por lo que no iniciamos desarrollo nuevo sobre él. No usamos Copilot Studio.

Detalles del stack:

Runtime: código propio en Node.js usando CloudAdapter más el middleware authorizeJWT del Agents SDK, corriendo en contenedor Docker autoalojado. No usamos Azure App Service ni Azure Functions; el servicio vive en nuestra propia infraestructura de borde, expuesto públicamente vía túnel de Cloudflare y reverse proxy.

Registro y canalización: Azure Bot Service (recurso Azure Bot), que sigue siendo la capa correcta de registro y de canal. Lo que fue reemplazado es el SDK, no el servicio.

Credencial: client secret, vigente y no expirado.

Configuración de autenticación verificada en código: el audience esperado por el middleware es igual al Client ID, que es igual al App ID (9e1d474f-c797-4dfe-b355-6721208ec66f). Al estar configurado el tenantId, los issuers quedan acotados al tenant, que es el comportamiento SingleTenant correcto y coherente con el registro en Azure.

App de Teams: app personalizada instalada por sideload. Manifest versión 1.17, botId igual al App ID, scopes ["team"], sin permisos de Microsoft Graph y sin RSC (Resource-Specific Consent) en esta fase.

3. ¿Disponen de registros, IDs de correlación o detalles adicionales de los errores?

Sí, tenemos registros exhaustivos — y el hallazgo central es que no hay ningún error que registrar, porque no llega ninguna petición. Instrumentamos tres capas independientes de observación y en las tres el resultado con tráfico de Teams es cero:

Capa 1, aplicación (handler): observa las actividades después de que authorizeJWT las valida. Resultado con Teams: 0 actividades.

Capa 2, endpoint (middleware previo a la autenticación): observa toda petición entrante antes de authorizeJWT, incluidas las que serían rechazadas por token inválido. Resultado con Teams: 0 peticiones con channelId=msteams.

Capa 3, borde de red (access log del reverse proxy): registra de absolutamente toda petición que llega al host el método, la URI, el status, el User-Agent, la IP real del cliente (Cf-Connecting-Ip) y la presencia del header Authorization. Resultado: ninguna petición a /api/messages proviene de un rango IP de Microsoft o Azure.

Sobre la cobertura de ese registro, para que puedan confiar en el dato: el contenedor no publica su puerto al host, por lo que el reverse proxy es la única vía de entrada externa posible — nada puede esquivar el borde. El log es continuo, sin rotación, y abarca 80 peticiones desde el 2026-07-29 07:02:56Z hasta el 2026-07-30 04:09:07Z. Sobrevivió incluso al reinicio del proxy de las 18:56:18Z sin perder continuidad.

Sobre IDs de correlación: no podemos aportar activityId, conversationId ni correlationId de Bot Framework, precisamente porque ninguna actividad de Teams llega. Esos identificadores los genera el Connector en la petición que nunca recibimos. Tampoco hemos registrado nunca el User-Agent Microsoft-SkypeBotApi (el del connector del canal de Teams) proveniente de una IP de Microsoft.

Detalles adicionales y descartes ya hechos de nuestro lado:

Auditamos uno por uno los 24 eventos HTTP 401 de todo el historial del bot. Resultado: 23 son sondas de prueba nuestras sin header Authorization, y 1 es un replay lanzado desde nuestro propio servidor (Cf-Connecting-Ip 160.34.216.121, que es nuestra IP de egress verificada en vivo). No existe ningún 401 con un JWT genuino de Bot Service. El único evento "Audience mismatch" del historial (2026-07-29 08:17:01.428Z) es exactamente ese replay: traía un JWT y el User-Agent de Microsoft, pero se originó en nuestra propia IP y con un cuerpo de 93 bytes, frente a los 598-713 bytes de las actividades genuinas. No es una entrega viva de Teams y no indica configuración errónea.

Verificamos en el código del SDK instalado que un desajuste de tipo de app (SingleTenant vs MultiTenant) no puede producir "Audience mismatch": el audience siempre es el clientId, independientemente del tipo; un desajuste de tipo se manifestaría como error de issuer o de firma.

El endpoint público, la ruta de red completa (Cloudflare, túnel, reverse proxy, contenedor) y la validación de JWT con CloudAdapter y authorizeJWT están verificados en funcionamiento: hemos observado round-trips completos de ida y vuelta de actividades genuinas de Microsoft por el canal Web Chat / DirectLine sobre esta misma ruta e infraestructura, con IP de Azure, JWT validado y HTTP 200. Es decir, cuando el Bot Framework Connector emite el POST, nuestro endpoint lo recibe y lo responde correctamente. Podemos repetir esa prueba en este bot en el momento que lo pidan y entregar la línea de log correspondiente.

Traza del lado del cliente de Teams: al enviar la @mención, la inspección de red del cliente (herramientas de desarrollador, pestaña Network) muestra que el POST interno al endpoint "messages" devuelve HTTP 201 Created. El cliente entrega el mensaje correctamente y el servicio de Teams lo admite.

Historial de fallo relevante: la instalación de la app en Teams ha fallado previamente con el error BulkMembershipRequest.

Aviso de Azure Diagnostics pendiente de aclarar: el portal, en "Diagnosticar y solucionar problemas" de este bot, reporta "Bot Service detectó mensajes rechazados como 401 No autorizado, devueltos como 502 al cliente". Auditamos todo nuestro historial con visibilidad completa y no existe ningún 401 nuestro a una petición originada en Azure. Les solicitamos el rango temporal exacto y, si es posible, los timestamps concretos que resume ese aviso, para cerrar formalmente esa pista. Nuestra hipótesis es que corresponde a una ventana anterior al inicio de nuestro logging de borde (2026-07-29 07:02:56Z), cuando el messaging endpoint estuvo apuntando temporalmente a otro servicio de prueba con credenciales distintas, lo que produciría exactamente ese patrón de 401 devuelto como 502. Si el aviso cae dentro de la ventana en que sí tenemos visibilidad completa, sería un hallazgo nuevo e indicaría que Bot Service está fallando antes de llegar a nosotros.

Podemos entregar bajo solicitud el access log crudo del borde en formato JSON para el periodo indicado, y repetir cualquier prueba con instrumentación activa en la ventana que ustedes definan.

Encuadre y petición concreta

Nuestra infraestructura está verificada sana y nuestro equipo de infraestructura lo confirmó formalmente: red, TLS, routing, túnel de Cloudflare, reverse proxy, App ID, Tenant ID, tipo de app SingleTenant, vigencia del client secret y alcanzabilidad server-to-server del messaging endpoint. La configuración de autenticación es coherente y está verificada en código. El canal de Teams está habilitado sin errores en el portal, y el botId del manifest es igual al App ID.

Dado que nuestro endpoint recibe y responde correctamente las actividades genuinas que el Bot Framework Connector le entrega por otros canales sobre la misma ruta de red, que el cliente de Teams devuelve HTTP 201 al enviar el mensaje, y que en tres capas independientes de observación no aparece ni una sola petición de Teams, el fallo queda aislado por eliminación al tramo "servicio interno de Teams → Bot Framework Connector → messaging endpoint". Ese segmento no es observable ni configurable desde el portal del Azure Bot ni desde nuestra red, y por eso necesitamos su ayuda. Seguir enviando mensajes de prueba desde Teams no aporta información nueva.

Nuestra petición es concreta. Solicitamos que tracen del lado de Microsoft:

Por qué el canal de Teams no está relayando las actividades del App ID 9e1d474f-c797-4dfe-b355-6721208ec66f, en el tenant a972e859-2d0c-4662-88b5-e6270fcf1113, hacia el messaging endpoint configurado.

Si existen políticas de apps del tenant de Teams (app permission policies o app setup policies), falta de consentimiento de administrador, o configuración de RSC a nivel organización que estén impidiendo que el bot de una app personalizada reciba mensajes, aun cuando la app se muestra e instala correctamente.

El estado real de la instalación de la app y de la membresía del bot en la conversación, considerando el fallo previo de BulkMembershipRequest.

El rango temporal exacto del aviso "401 No autorizado devuelto como 502" de Azure Diagnostics para este bot.

Quedamos atentos y disponibles para habilitar cualquier prueba adicional, con logging en vivo, en la ventana que ustedes indiquen.

Hola @Anonymous

Gracias por compartir los detalles. El comportamiento que describes sugiere que los errores 502/504 ocurren cuando el bot no devuelve una respuesta dentro del tiempo esperado.

Los canales Direct Line y Web Chat muestran estos errores al cliente cuando la solicitud supera el tiempo de espera. Te recomendamos revisar los registros y la telemetría de tu bot para identificar solicitudes que tardan más de 15 segundos, problemas de configuración del endpoint o incidencias transitorias de red.

Si el bot está aceptando las solicitudes pero no responde, la investigación debe centrarse en la lógica conversacional del bot y en cualquier procesamiento de backend que pueda estar retrasando la respuesta.

¿Podrías compartir la siguiente información?

¿El problema ocurre de forma constante o intermitente?

¿Qué plataforma estás utilizando para implementar el bot (Bot Framework SDK o Copilot Studio)?

¿Dispones de registros, IDs de correlación o detalles adicionales de los errores?

Con esta información podremos ayudarte a identificar la causa raíz con mayor precisión.

Gracias.