基于.NET Core 3.1的Bot发布生产后第二条SendActivityAsync消息未收到

排查步骤 #

• 优先调取Bot的运行日志，重点查看第二次SendActivityAsync调用的执行状态：检查是否抛出未捕获异常、返回非200的HTTP状态码，若返回429状态码即可判定为触发限流。
• 检查生产环境托管服务的请求日志，确认两次SendActivityAsync请求是否都成功发送到了Bot Framework服务端，有没有出现第二次请求未发出的情况。
• 核对两次调用时的会话ID是否一致，排除会话上下文意外失效的问题。

常见问题及解决方案 #

场景1：触发生产环境消息限流 #

Bot Framework生产环境对单会话的消息发送频率有默认限制，本地模拟器没有该限制，因此会出现本地运行正常、生产环境第二条消息被拦截的情况。
解决方案：

• 方案1：在两次发送调用之间增加100ms左右的延迟，错开发送时间：

await stepContext.Context.SendActivityAsync(replyText1).ConfigureAwait(false);
await Task.Delay(100).ConfigureAwait(false);
await stepContext.Context.SendActivityAsync(replyText2).ConfigureAwait(false);

• 方案2（更推荐）：使用批量发送接口一次性发送多条消息，框架会自动适配限流规则：

var activityList = new List<IActivity>
{
    MessageFactory.Text(replyText1),
    MessageFactory.Text(replyText2)
};
await stepContext.Context.SendActivitiesAsync(activityList.ToArray()).ConfigureAwait(false);

场景2：对话状态存储异常 #

如果生产环境使用分布式状态存储（如Redis、Azure存储），第一次消息发送后出现状态持久化失败，会导致第二次调用时上下文失效，消息无法正确路由。
解决方案：

• 检查状态存储的连接配置、访问权限是否正常，开启状态存储操作日志，排查是否有写入失败的报错。
• 确认对话流转逻辑没有在两次发送之间意外重置会话ID、修改上下文参数。

场景3：对接通道特有限制 #

部分对接通道（如Teams、第三方网页端、企业微信等）本身有消息推送频率限制，会主动丢弃短时间内收到的第二条同会话消息。
解决方案：

• 优先使用批量发送接口发送多条消息，若通道不支持批量发送，可适当延长两次发送之间的延迟时长到500ms左右。

内容的提问来源于stack exchange，提问作者Raj Gohel