Reactor Netty中"Expect: 100-continue"请求头引发的ChannelOutboundBuffer警告问题分析

问题背景

在基于Spring Cloud Gateway构建的微服务架构中，当客户端发送包含Expect: 100-continue请求头的HTTP请求时，系统虽然能正确处理请求并返回预期的100和202状态码，但会在日志中记录一条令人困惑的警告信息："ChannelOutboundBuffer: Failed to mark a promise as success because it has succeeded already"。

技术细节

HTTP 100 Continue机制

HTTP/1.1规范中定义的100 Continue状态码是一种优化机制，允许客户端在发送较大请求体前先确认服务器是否愿意接收请求。当客户端发送包含Expect: 100-continue头的请求时，服务器应首先响应100 Continue，然后客户端再发送请求体。

Netty的Promise机制

Netty使用Promise来表示异步操作的结果。在ChannelOutboundBuffer中，当数据写入完成时，会通过Promise通知调用方操作结果。Promise的一个关键特性是只能被完成一次（成功或失败），重复完成会导致警告。

问题根源

通过分析堆栈和重现问题，发现当同时满足以下条件时会出现该警告：

1. 启用了Netty服务器指标收集（通过metrics(true)配置）
2. 客户端请求包含Expect: 100-continue头
3. 服务器正确处理了100 Continue流程

根本原因是指标收集处理器(HttpServerMetricsHandler)和核心处理器在处理100 Continue响应时，都尝试完成同一个Promise对象，导致第二次完成操作触发警告。

解决方案

Reactor Netty团队已经确认并修复了这个问题。修复方案主要涉及：

1. 在指标收集处理器中优化Promise处理逻辑
2. 确保100 Continue响应流程中Promise只被完成一次
3. 保持与Netty核心处理器的兼容性

最佳实践

对于使用Reactor Netty的开发者，建议：

1. 及时升级到包含修复的版本
2. 对于关键业务系统，应监控并处理此类警告日志
3. 理解100 Continue机制对性能的影响，根据业务场景合理使用

总结

这个问题展示了分布式系统中协议实现细节的重要性。虽然表面上是无害的警告日志，但深入理解其背后的机制有助于构建更健壮的系统。Reactor Netty团队快速响应并修复此类问题，体现了开源社区对代码质量的重视。