CloudflareのImagesチームがhyper HTTPライブラリで競合状態を発見

CloudflareのImagesサービスは、Workers上でRustで構築されており、クライアント接続を処理するためにhyper HTTPライブラリを使用しています。2025年12月にチームがImagesバインディングを再設計し、中間サービスを経由する代わりにローカルのUnixソケットを使用するようにしたところ、大きな画像変換で断続的な障害が発生し始めました。レスポンスは200ステータスとメガバイトを約束するContent-Lengthヘッダーを返すものの、ボディが途中で切れてしまう——3.3 MBのレスポンスのうち、時には約200 KBしか届かないこともありました。

バグはhyperのレスポンスフラッシュロジックにおける競合状態でした。ソケットのもう一方の端にあるリーダーがライターよりも遅い場合（数ミリ秒でも）、hyperの内部バッファが満杯になり、ソケットのアウトバウンドバッファが空くのを待つ必要がありました。適切な並行性条件下では、hyperはすべてのデータがフラッシュされる前にソケットでshutdownを発行し、レスポンスを切り詰めていました。

チームは6週間デバッグに費やしました。バグをオンデマンドで再現できる再現環境を構築し、タイムアウトを除外し、hyperバージョン0.14から1.8までテストし（バグはすべてのバージョンで発生）、Workersランタイムに問題がないことを確認しました。分散トレーシングにより、問題はImagesサービスを通るバインディングパスに絞り込まれました。

修正は驚くほど小さなものでした：hyperに4行のコードを追加し、すべてのバッファリングされたデータがソケットにフラッシュされた後にのみshutdownが呼び出されるようにしました。Cloudflareは修正を上流に貢献しました。

これは、hyperのような実績のあるライブラリでも、特定の本番環境条件下でのみ表面化する微妙な並行性バグが存在し得ること、そして注意深く体系的なデバッグがそれらを特定できることを示す素晴らしい例です。