Cloudflare шесть недель искала баг в hyper: ответы возвращали 200 OK, но приходили не полностью

Cloudflare рассказала, как шесть недель искала почти невидимый баг в hyper — популярной HTTP-библиотеке для Rust. Ошибка проявлялась неприятно: сервис возвращал 200 OK, в логах не было явных сбоев, но клиент получал не весь ответ. Например, вместо нескольких мегабайт данных доходили только первые сотни килобайт.

В итоге причина оказалась не в бизнес-логике, не в обработке изображений и не в клиентском коде. Данные терялись на уровне соединения: hyper мог закрыть сокет до того, как полностью вытолкнул тело ответа из внутреннего буфера.

Проблему нашли в сервисе Cloudflare Images. Он написан на Rust, работает на edge-сети Cloudflare и использует hyper для обработки HTTP-соединений.

Сценарий был такой: разработчик через Workers обращался к Images binding — программному интерфейсу для обработки изображений. В одном из пользовательских пайплайнов изображение сначала собиралось из нескольких крупных исходников, а затем дополнительно сжималось, перекодировалось и масштабировалось через другой слой обработки.

Снаружи всё выглядело странно. Внутренний слой возвращал HTTP 200, заголовок Content-Length обещал несколько мегабайт, но тело ответа оказывалось обрезанным. В одном из случаев вместо ожидаемых 3,3 МБ до клиента дошло около 200 КБ.

Если бы ошибка была обычной — тайм-аут, падение процесса, некорректный статус, исключение в логах, — её нашли бы быстрее. Но система считала, что всё прошло успешно.

Незадолго до этого Cloudflare изменила архитектуру Images binding. Раньше данные шли через внутренний промежуточный сервис FL, который обрабатывает входящий трафик в сети Cloudflare. Позже его заменили более прямым локальным взаимодействием: сервисы стали общаться через Unix-сокеты на одной машине.

Сам баг при этом не появился из-за новой