在C#中避免Azure DocumentDB的Task Cancelled Exception问题

嘿，这个场景我太熟悉了！之前在Web应用里用单例DocumentClient做多线程读写时，也踩过Task Cancelled Exception的坑。咱们从几个核心方向来排查和解决：

1. 确保DocumentClient初始化配置合理 #

DocumentClient本身是线程安全的，单例模式没问题，但初始化时的配置直接影响稳定性：

• 调整请求超时时间：默认的RequestTimeout可能偏短（比如10秒），网络波动或数据量大时容易触发超时取消。初始化时把它设长一点：

  var connectionPolicy = new ConnectionPolicy
  {
      RequestTimeout = TimeSpan.FromSeconds(30), // 根据业务场景灵活调整
      // 其他配置...
  };
  Client = new DocumentClient(yourEndpoint, yourKey, connectionPolicy);
  

• 配置合适的重试策略：Cosmos DB SDK内置了重试，但默认策略可能应对不了频繁的临时故障。可以换成指数退避重试：

  connectionPolicy.RetryPolicy = new ExponentialRetry(TimeSpan.FromMilliseconds(100), 5);
  

  这样遇到限流（429）或临时网络问题时，SDK会自动重试，减少因重试不及时导致的任务取消。

2. 避免调用方的CancellationToken意外干扰 #

很多Task Cancelled Exception并不是SDK的问题，而是调用方传递了被取消的Token，或者上层上下文被销毁：

• 显式管理CancellationToken：修改SaveItem方法，允许传入Token（默认用空Token），避免上层的取消信号影响SDK请求：

  public static async Task SaveItem<T>(T item, CancellationToken cancellationToken = default)
  {
      try
      {
          // 把Token传递给SDK方法，同时用ConfigureAwait(false)避免捕获调用方上下文
          await Client.UpsertDocumentAsync(Uri, item, cancellationToken: cancellationToken)
                      .ConfigureAwait(false);
      }
      catch (TaskCanceledException ex)
      {
          // 区分主动取消和超时两种场景
          if (ex.CancellationToken.IsCancellationRequested)
          {
              // 业务侧主动取消，按需求处理
          }
          else
          {
              // 超时导致的取消，可考虑手动重试或记录告警
          }
      }
      catch (Exception ex)
      {
          // 其他异常处理逻辑
      }
  }
  

• 禁止同步阻塞调用：绝对不要在同步方法里用SaveItem(item).Wait()或SaveItem(item).Result，这会导致线程池阻塞，甚至死锁，间接引发任务被取消。要保持async/await的调用链贯穿整个流程。

3. 验证全局Uri的正确性 #

全局定义的DocumentCollection Uri一定要确保是正确的，推荐用UriFactory.CreateDocumentCollectionUri(databaseId, collectionId)生成。如果Uri错误，虽然多数情况会返回400 BadRequest，但极端情况下也可能因请求无法正确路由而触发超时取消，这点别忽略。

4. 监控线程池资源 #

Web应用中如果并发请求过多，线程池资源耗尽也会导致任务被取消。可以通过日志监控线程池的队列长度和活跃线程数，必要时做限流处理，避免短时间内发起大量Cosmos DB请求。

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