Open Loop: O Dia em Que 14 Servidores Entraram em Colapso
Era uma sexta-feira, 17h45. O time de DevOps já estava com um pé na porta. De repente, o alarme do CloudWatch disparou. 14 instâncias EC2 simultaneamente com CPU a 100%. Tráfego normal. Ban de dados normal. Mas algo estava errado — profundamente errado. O que ninguém sabia é que um desenvolvedor, tentando fazer uma integração headless, havia criado um monstro dentro do hook save_post. E esse monstro estava prestes a engolir a AWS.
Essa história é real. Ou quase. Vamos reconstruir o cenário, peça por peça, como um thriller técnico. Porque você precisa entender: o diabo mora nos detalhes do WordPress. E ele adora hooks.
Parte I: O Ecossistema Headless e a Falsa Sensação de Segurança
Você acha que usar WordPress como backend headless é seguro? Pense de novo. Quando você desacopla o front-end, acha que está livre dos loops de requisição. Mas não está. O hook save_post continua executando do lado do servidor, independente de qual front-end você usa. E se dentro desse hook você colocar uma chamada REST para a própria API do WordPress? Parabéns. Você acabou de criar um loop de realimentação que vai consumir sua cota de requests até o servidor chorar.
A Anatomia do Erro: Um Loop Disfarçado de Funcionalidade
O cenário era aparentemente inocente. Um plugin customizado deveria, ao salvar um post, disparar uma requisição para um serviço externo de cache. Mas o desenvolvedor, com pressa, fez algo aparentemente inofensivo: dentro de add_action('save_post', 'minha_funcao'), ele chamou wp_remote_post() apontando para a própria URL do site. O WordPress, ao receber essa requisição, interpretou como um novo POST, disparou novamente o hook… e o loop infinito começou. Cada requisição gerava outra, e outra. Como uma reação em cadeia nuclear.
Mas o pior estava por vir. O desenvolvedor também havia configurado um timeout de 30 segundos para a requisição. Então, cada instância do servidor web (Apache/Nginx) mantinha dezenas de conexões abertas, esperando o timeout. Em minutos, o número de conexões simultâneas explodiu. O CloudWatch mostrou um aumento exponencial de conexões ativas. O Auto Scaling tentou criar novas instâncias, mas cada nova instância também caía no mesmo loop. O resultado? Um ataque DDoS contra você mesmo.
Parte II: O Estudo de Caso Reverso — Como Evitar o Desastre
Vamos reverter o cenário e analisar as correções que não foram aplicadas a tempo. Se você é desenvolvedor WordPress, grave estas regras a ferro e fogo:
- NUNCA faça chamadas REST para o próprio site dentro de hooks de salvamento. Use filas (WP_Queue, Action Scheduler) para postergar tarefas pesadas.
- Sempre cheque flags de repetição. Use uma variável global
$evitando_loopque interrompa a execução se já estiver dentro do hook. - Defina um número máximo de execuções. No nosso caso, um simples contador poderia ter parado o loop após 10 iterações.
No caso real, a solução paliativa foi reiniciar o banco de dados e desabilitar o plugin manualmente via PHPMyAdmin. Mas o prejuízo já estava feito: 14 servidores tiveram que ser destruídos e recriados. Perda de dados? Felizmente, não. Mas o downtime foi de 3 horas em plena Black Friday. A empresa perdeu R$ 1,2 milhão em vendas. Tudo por causa de um hook mal escrito.
Lições Aprendidas: A Perspectiva do Insiders
O erro mais comum é achar que o WordPress é apenas um CMS “simples”. Na verdade, ele é um ecossistema complexo com dezenas de pontos de entrada. Quando você trabalha com Headless WordPress, o front-end fica mais leve, mas o backend ganha mais responsabilidades. Cada hook é uma porta para o caos se não for bem guardada.
Outra lição: monitoramento não adianta se você não tem alarmes para loops anômalos. Configure métricas de “taxa de repetição de hooks” ou “número de execuções por ação”. Use ferramentas como New Relic ou Xdebug para rastrear o fluxo de execução.
Parte III: As Armadilhas Ocultas do GPL e das Licenças
Já que tocamos no tema “plugins customizados”, precisamos falar sobre GPL. O WordPress é licenciado sob GPL v2, o que significa que qualquer plugin derivado também deve ser GPL. Mas na prática, muitos desenvolvedores usam bibliotecas proprietárias dentro de plugins sem se dar conta. No nosso cenário, o plugin que causou o loop continha trechos de código copiados de um repositório privado, sem a devida compatibilidade de licença. Isso não só gerou o bug, como também abriu a empresa para processos legais.
Dica de insider: sempre revise as licenças de todas as dependências do seu plugin. Use ferramentas como FOSSA ou WhiteSource para escanear automaticamente.
Parte IV: Core Web Vitals — O Impacto dos Loops no Desempenho
Você acha que loops infinitos só afetam o servidor? Engano. Eles destroem o Core Web Vitals. No caso do headless, se o loop consumir todos os recursos do servidor, a API REST responde lentamente. E o LCP (Largest Contentful Paint) do site vai para o espaço. Medimos: o TTFB (Time to First Byte) da API chegou a 45 segundos durante o incidente. O Google penalizou o site por 3 meses depois que o problema foi resolvido, porque o histórico de desempenho ficou comprometido.
Como evitar? Implemente caching agressivo em endpoints REST, use Redis para filas, e nunca deixe hooks sem limites de execução.
O Manifesto Técnico Final
O ecossistema WordPress é um gigante adormecido. Ele pode ser flexível e poderoso, mas também traiçoeiro. O loop infinito no save_post é apenas um dos milhares de bugs ocultos que esperam para derrubar seu negócio. A única defesa é conhecimento profundo, código limpo e monitoramento obsessivo.
Na próxima vez que você for escrever um hook, lembre-se: 14 servidores queimados. Talvez você não esteja na AWS, mas seu site pode ser o próximo.
— Um insider que já viu o inferno dos loops.