HTTP/2 PROTOCOL_ERROR and TaskCanceledException during FCM requests FCM 请求出现 HTTP/2 PROTOCOL_ERROR 和 TaskCanceledException

未关闭
  • 哪里不对？
#591 1 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
42/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
csharp
领域
backend

调研方向

Start by tracing the FCM request send and retry path in the SDK, then inspect its HTTP client factory and handler configuration. Identify which diagnostics can distinguish cancellation sources and correlate retries with the final send result; done means providing evidence-based guidance on configuration, logging severity, and when these failures need investigation. The issue names no source files or tests.

由索引模型根据 Issue 内容生成。

描述

Environment / 环境

  • FirebaseAdmin: Custom build based on 3.0.1 / 基于 3.0.1 的自定义构建
  • Product: FCM
  • OS: Linux (Kubernetes)
  • .NET: 10

Description / 问题描述

Over the past few days, we have frequently observed the following exceptions during FCM requests. Repeated cancellation exceptions are concentrated on one pod. No application cancellation token is passed in the normal send path.

最近几天，FCM 请求频繁出现以下异常，其中取消异常集中在一个 Pod 持续发生。普通发送路径未传入业务取消令牌。

HTTP/2 protocol error / HTTP/2 协议错误
System.Net.Http.HttpRequestException:
The HTTP/2 server sent invalid data on the connection.
HTTP/2 error code 'PROTOCOL_ERROR' (0x1).
 ---> System.Net.Http.HttpProtocolException
 at System.Net.Http.Http2Connection.Http2Stream.ReadResponseHeadersAsync(...)
 at System.Net.Http.Http2Connection.SendAsync(...)
 at Google.Apis.Http.ConfigurableMessageHandler.SendAsync(...)
Cancellation / 取消异常
System.Threading.Tasks.TaskCanceledException:
The operation was canceled.
 at System.Net.Http.Http2Connection.Http2Stream.<>c.<WaitForDataAsync>b__88_0(...)
 at System.Threading.CancellationTokenSource.ExecuteCallbackHandlers(...)
 at System.Threading.TimerQueue.FireNextTimers()
--- End of stack trace from previous location ---
 at Google.Apis.Http.ConfigurableMessageHandler.SendAsync(...)
 at System.Net.Http.HttpClient.<SendAsync>g__Core|83_0(...)

Stack traces are shortened and sanitized. / 堆栈已精简并脱敏。

HTTP configuration / HTTP 配置

We provide a custom Google.Apis.Http.IHttpClientFactory backed by SocketsHttpHandler:

我们通过自定义 Google.Apis.Http.IHttpClientFactory 使用以下 SocketsHttpHandler 配置：

new SocketsHttpHandler
{
    AllowAutoRedirect = false,
    AutomaticDecompression = decompression,
    EnableMultipleHttp2Connections = true,
    PooledConnectionLifetime = TimeSpan.FromMinutes(5),
};

decompression is either GZip | Deflate or None, depending on the SDK factory options.

decompression 根据 SDK 工厂选项设置为 GZip | Deflate 或 None。

A custom DelegatingHandler sets the version policy and logs exceptions before rethrowing them:

自定义 DelegatingHandler 设置版本策略，并记录异常后重新抛出：

try
{
    request.VersionPolicy = HttpVersionPolicy.RequestVersionOrHigher;
    return await base.SendAsync(request, cancellationToken);
}
catch (Exception ex)
{
    logger.LogWarning(ex, "Firebase HTTP request failed");
    throw;
}

Questions / 希望确认

Could our custom HTTP configuration contribute to these exceptions? Are there recommended configuration changes or fixes?
自定义 HTTP 配置是否可能导致这些异常？是否有推荐的配置调整或修复方案？

What diagnostics should we collect to identify the cancellation source and correlate retry attempts with the final send result?
建议收集哪些诊断信息，以定位取消来源并关联重试与最终发送结果？

If the SDK retries successfully and the final send succeeds, can these inner-handler exceptions be treated as transient and logged at a lower severity? Under what conditions should they require further investigation?
如果 SDK 重试后最终发送成功，是否可以将这些内部 Handler 异常视为瞬时故障并降低日志级别？哪些情况下仍需要进一步排查？

主要语言
C#
星标
407
派生
147
平均合并
2 天 10 小时
30 天内合并 PR
12

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

firebase/firebase-admin-dotnet 的其他 Issue

查看 firebase/firebase-admin-dotnet 的全部 Issue

相似的 Issue

更多 C# Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。