使用GraphServiceClient调用Microsoft Graph突发大量Unexpected exception问题排查

嘿，我之前也碰到过Graph调用突然掉链子的情况，太闹心了！先帮你搞定请求ID的问题，再说说排查思路。

一、获取被封装的请求ID #

GraphServiceClient的请求ID其实藏在两个地方，很容易拿到：

1. 从ServiceException中直接提取 #

如果你的异常是ServiceException（Graph SDK抛出的标准异常），直接从异常对象里就能拿到请求ID，代码示例：

try
{
    // 你的Graph调用代码，比如获取用户信息
    var user = await _graphClient.Me.GetAsync();
}
catch (ServiceException ex)
{
    // 提取请求ID
    var requestId = ex.Error?.RequestId;
    // 把请求ID和你的异常信息、堆栈、时间一起记录下来
    Console.WriteLine($"异常时间: {DateTime.Now}, 请求ID: {requestId}, 错误信息: {ex.Message}");
    Console.WriteLine($"堆栈追踪: {ex.StackTrace}");
}

2. 用自定义Handler拦截请求/响应 #

如果异常没有被包装成ServiceException，或者你想提前记录所有请求的ID，可以给GraphClient加一个自定义的DelegatingHandler来拦截响应头：

// 自定义日志Handler
public class GraphRequestLoggingHandler : DelegatingHandler
{
    public GraphRequestLoggingHandler(HttpMessageHandler innerHandler) : base(innerHandler) { }

    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        var response = await base.SendAsync(request, cancellationToken);
        
        // 从响应头获取request-id
        if (response.Headers.TryGetValues("request-id", out var requestIds))
        {
            var requestId = requestIds.FirstOrDefault();
            // 这里可以把requestID和请求路径、响应状态码一起记录到日志系统
            Console.WriteLine($"请求路径: {request.RequestUri}, 请求ID: {requestId}, 状态码: {response.StatusCode}");
        }
        
        return response;
    }
}

// 初始化GraphClient时添加这个Handler
var httpClient = new HttpClient(new GraphRequestLoggingHandler(new HttpClientHandler()));
var graphClient = new GraphServiceClient(httpClient, new DelegateAuthenticationProvider(async (msg) =>
{
    // 你的令牌获取逻辑，比如从ADAL/MSAL拿到accessToken
    var accessToken = await GetAccessTokenAsync();
    msg.Headers.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
}));

二、排查异常的核心思路 #

拿到请求ID后，你可以结合这些方向排查：

• 检查认证有效性：看看你的令牌是否过期、权限是否被撤销（比如应用注册的API权限有没有被改动）。可以用令牌解析工具看看令牌里的scope和过期时间。
• 排查节流问题：如果收到429状态码，就是触发了Graph的请求限流。可以看看最近是不是请求频率突然变高，或者调整请求逻辑，加入重试机制（SDK其实自带重试，你可以检查配置）。
• 确认服务端状态：有时候是Microsoft Graph本身的故障，你可以查看官方的Microsoft 365服务状态，确认是否有全局或区域性的服务中断。
• 对比代码变更：回忆一下最近有没有改动Graph调用的代码、升级SDK版本，或者修改了请求参数/端点。比如SDK升级可能带来兼容性问题，或者请求的字段被废弃了。
• 用请求ID查详情：拿到请求ID后，你可以在官方的Graph错误排查工具中输入ID，获取更详细的错误诊断信息，比如具体是哪个环节出错了。

把你手头的代码示例、堆栈追踪、异常时间和拿到的请求ID对应起来，很快就能定位到原因啦！

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