Azure Communication Service聊天功能部署到Azure应用后无法正常运行

优先排查的常见根因 #

• 身份认证配置差异
  本地调试时通常使用管理员权限的连接字符串硬编码，部署到Azure应用后大概率使用托管身份/密钥保管库获取凭证，凭证缺少chat.read或者participant.read权限时，ACS接口会自动过滤无权限读取的参会者信息，仅返回当前请求者自身的条目，刚好出现统计结果为1的情况。
  你可以先打印部署环境下调用参会者列表接口返回的完整响应，检查是否存在hidden属性标记的被过滤条目，或者响应头的ms-cs-restricted-participants字段是否有值。

• 环境变量配置错误
  检查部署环境的以下配置项是否和本地一致：

  • ACS资源的终结点（Endpoint）是否填错为其他环境的资源地址
  • 聊天线程ID（Thread ID）是否是硬编码的本地测试值，未随部署同步更新
  • 加入聊天线程的逻辑是否遗漏了生产环境下的用户ID前缀配置，导致第二个用户实际未成功加入线程

• 网络访问限制
  本地调试时你的IP在ACS资源的防火墙白名单中，部署后Azure应用的出站IP未添加到ACS防火墙允许列表，会导致部分请求被截断，参会者列表接口仅返回部分数据。你可以在Azure门户的ACS资源「网络」页签下，确认是否启用了IP访问限制，将Azure应用的所有出站IP都添加到白名单中。

快速验证方法 #

你可以在部署环境的代码中插入如下调试日志，定位具体错误：

// 示例为C# SDK，其他语言逻辑一致
var participants = await chatThreadClient.GetParticipantsAsync();
Console.WriteLine($"接口返回参会者总数：{participants.Count()}");
foreach(var p in participants)
{
    Console.WriteLine($"参会者ID：{p.Id}，角色：{p.Role}");
}
// 打印响应头信息确认是否有权限限制
var response = participants.GetRawResponse();
Console.WriteLine($"响应头ms-cs-restricted-participants：{response.Headers.TryGetValue("ms-cs-restricted-participants", out var val) ? val : "无"}");

如果日志中ms-cs-restricted-participants有值，100%是凭证权限问题，给托管身份分配对应ACS权限即可解决。

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