使用Microsoft Graph API v1.0批量创建Planner任务时随机失败的解决方案咨询

针对你在.NET Core中使用Microsoft Graph API v1.0执行Planner任务批量创建时出现的随机400/500错误、任务丢失问题，可通过以下方案实现无丢失的批量调用：

1. 针对瞬时错误的智能重试机制 #

使用Polly库实现灵活的重试策略，针对Graph API常见的瞬时错误（如限流、服务器内部错误）自动重试，避免因临时波动导致任务创建失败：

• 配置重试策略：针对HTTP状态码429（限流）、500、502、503、504，以及Graph API特定的错误码（如TooManyRequests）进行重试，同时设置指数退避间隔（避免频繁请求加重服务器负担）
• 代码示例：

// 注册Polly重试策略
var retryPolicy = Policy
    .Handle<ServiceException>(ex => 
        ex.StatusCode is HttpStatusCode.TooManyRequests or HttpStatusCode.InternalServerError or HttpStatusCode.BadGateway 
        or HttpStatusCode.ServiceUnavailable or HttpStatusCode.GatewayTimeout
        || ex.Error?.Code == "TooManyRequests")
    .WaitAndRetryAsync(3, retryAttempt => 
        TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)));

// 包装Graph请求
await retryPolicy.ExecuteAsync(async () => 
{
    var plannerTask = new PlannerTask
    {
        Title = "任务标题",
        PlanId = planId,
        BucketId = bucketId,
        Assignments = new PlannerAssignments
        {
            // 填充分配信息
        }
    };
    await graphClient.Planner.Tasks.PostAsync(plannerTask);
});

2. 使用Graph批量请求减少请求次数 #

将多个任务创建请求打包为一个批量请求，降低HTTP连接开销，减少出错概率：

• 构建批量请求内容，每个子请求包含唯一ID，便于后续区分成功/失败任务
• 发送批量请求后，遍历响应结果，对失败的子请求单独进行重试
• 代码示例：

var batchContent = new BatchRequestContent();

// 循环添加任务创建请求
foreach (var task in taskList)
{
    var request = graphClient.Planner.Tasks.ToPostRequestInformation(new PlannerTask
    {
        Title = task.Title,
        PlanId = planId,
        BucketId = bucketId
    });
    var batchRequestStep = new BatchRequestStep(Guid.NewGuid().ToString(), request);
    batchContent.AddBatchRequestStep(batchRequestStep);
}

// 发送批量请求
var batchResponse = await graphClient.Batch.PostAsync(batchContent);

// 处理响应
foreach (var step in batchResponse.BatchRequestSteps)
{
    var response = await batchResponse.GetResponseByIdAsync<PlannerTask>(step.Key);
    if (!response.IsSuccessStatusCode)
    {
        // 将对应失败任务加入重试队列
        var failedTask = taskList.First(t => t.BusinessId == /* 匹配任务的业务唯一标识 */);
        EnqueueFailedTask(failedTask);
    }
}

3. 状态跟踪与幂等性保障 #

通过业务层状态记录和幂等设计，避免任务重复创建或丢失：

• 在数据库中记录每个任务的业务ID、Graph任务ID、创建状态（待创建/创建中/已成功/创建失败）
• 创建任务前，先检查数据库中该任务的状态：若已成功则跳过，若失败则重试，若待创建则执行创建
• 利用业务唯一标识实现幂等，避免重复提交导致的异常

4. 错误分类与告警 #

区分瞬时错误和永久错误，避免无效重试：

• 捕获ServiceException后，根据错误码判断处理逻辑：
  • 瞬时错误（如TooManyRequests、5xx状态码）：自动加入重试队列
  • 永久错误（如InvalidRequest、ResourceNotFound）：记录错误日志并触发告警，不再重试
• 示例代码：

try
{
    await graphClient.Planner.Tasks.PostAsync(plannerTask);
}
catch (ServiceException ex)
{
    switch (ex.Error?.Code)
    {
        case "TooManyRequests":
        case "InternalServerError":
            // 加入重试队列
            break;
        case "InvalidRequest":
        case "ResourceNotFound":
            // 记录告警日志
            break;
        default:
            // 其他情况酌情处理
            break;
    }
}

额外注意事项 #

• 遵循Graph API的限流规则：当收到429错误时，需严格按照响应头Retry-After指定的时间间隔重试
• 控制批量请求的大小：Graph批量请求最多包含20个子请求，避免超出限制导致失败

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