Como a Cloudflare encontrou um bug na hyper HTTP library

A Cloudflare identificou um bug de condição de corrida na biblioteca hyper, usada para gerenciar conexões HTTP em Rust, que truncava respostas de imagens grandes sem retornar erro. O problema só aparecia quando o buffer do socket de Unix entre o serviço Images e o intermediário interno enchia, algo que não ocorria antes da troca do FL por Unix sockets em dezembro de 2025. O FL, por ser mais lento e ter overhead de rede, consumia os dados antes que o buffer enchesse. O novo intermediário, mais rápido, criou um ponto de estrangulamento sutil: o hyper descartava o resultado do flush sem verificar se ainda havia dados pendentes, encerrando a conexão prematuramente.

A correção foi mínima: quatro linhas de código que passaram a verificar o retorno de poll_flush antes de prosseguir. Em vez de usar let _ = poll_flush(), o código agora espera o Poll::Pending e continua o loop até que todo o buffer seja esvaziado. Isso não é apenas um ajuste de biblioteca, é um lembrete de que otimizações de desempenho podem expor falhas de tempo em camadas invisíveis, especialmente em sistemas distribuídos onde cada milissegundo conta.

Esse bug afeta diretamente a confiabilidade de serviços que dependem de streaming de dados grandes via HTTP/1, como APIs de processamento de imagem, vídeo ou arquivos binários. A ausência de erros visíveis, status 200 com corpo truncado, torna a detecção difícil e a falha silenciosa. Para equipes de DevOps e SREs, isso reforça a necessidade de observabilidade em nível de kernel, não só de aplicação. Monitorar syscalls como write e shutdown com ferramentas como strace pode revelar falhas que logs e traces distribuídos não capturam. É um caso clássico de como melhorias de latência podem introduzir novos tipos de falha, e como a engenharia de confiabilidade exige entender o sistema inteiro, da aplicação até o kernel.