Azure Functions Host 中 HTTP 中转服务的请求取消问题解析

问题背景

在 Azure Functions Host 项目中，DefaultHttpProxyService 组件在处理 HTTP 请求时存在一个重要的缺陷：未能正确处理请求取消的情况。这个问题在 .NET 隔离模式下特别明显，当客户端取消请求时，系统会抛出"Failed to proxy request with ForwarderError: RequestCanceled"的异常。

问题表现

当 Azure Functions 应用收到 HTTP 请求并被客户端取消时，系统会记录以下错误信息：

Sending InvocationCancel request for invocation: 'a11b8045-59cf-4db2-90eb-356d561e2fb2'
Exception while executing function: Functions.<YourFunctionName> ---> System.InvalidOperationException : Failed to proxy request with ForwarderError: RequestCanceled. System.IO.IOException : Unable to read data from the transport connection: The I/O operation has been aborted because of either a thread exit or an application request

技术分析

这个问题实际上由两个相互关联的缺陷组成：

1. Host 端问题

在 DefaultHttpProxyService 的实现中，代码没有正确处理 ForwarderError.RequestCanceled 的情况。无论工作进程或客户代码是否处理了取消令牌，当调用被取消时，系统都会生成这个错误消息。

核心问题代码位于 DefaultHttpProxyService 的请求处理逻辑中，它没有考虑请求被取消的情况，导致错误信息被错误地传播。

2. Worker 端问题

在 AspNetCore 工作进程扩展中存在另一个缺陷，破坏了取消行为的正确性。在 DefaultHttpCoordinator 中，当创建 ContextReference 时传入了取消令牌，但当函数调用被取消时，系统会取消同一个 CTS（CancellationTokenSource），而这个 CTS 正被 ContextReference 使用。

这导致在处理调用结果时，我们会得到一个已释放的 HttpContext，最终抛出 ObjectDisposedException 异常。

解决方案

Azure Functions 团队已经针对这两个问题分别进行了修复：

1. 对于 Host 端问题，修复已合并到主分支，并随 host 版本 4.x38 发布
2. 对于 Worker 端问题，修复已通过 NuGet 包更新发布，可以通过升级 AspNet Http 扩展包立即使用

影响与建议

虽然这个问题主要产生的是"噪音"级别的异常，不会实际影响函数的执行（如果正确处理了取消令牌，调用仍会运行到完成），但它确实会：

1. 污染日志系统
2. 可能触发基于异常数量的监控警报
3. 给开发人员带来困扰

对于生产环境，建议：

1. 升级到修复版本（host 4.1038.300+ 和最新的 worker 扩展）
2. 在函数代码中妥善处理取消令牌
3. 调整监控系统，过滤掉这类已知的"噪音"异常

总结

Azure Functions Host 中的这个 HTTP 中转服务问题展示了分布式系统中请求取消处理的复杂性。通过分析这个问题，我们不仅了解了 Azure Functions 内部的工作机制，也看到了微软团队如何系统地解决这类跨组件的问题。对于开发者而言，理解这类底层机制有助于更好地构建健壮的云原生应用。