Como a Zepto reduziu a memória dos pods Next.js de ~5 GB para ~1,2 GB ao conter um timer do react-query

O problema da Zepto não era um vazamento clássico. No SSR, o react-query v3 cria uma Query para cada useQuery renderizado e dispara na hora um timer de expiração de cache (Query.scheduleGc), de 2 a 5 minutos. No navegador isso faz sentido, porque o timer é cancelado quando um componente assina a query. No servidor a assinatura acontece dentro de useEffect, que não roda durante o SSR. O timer corre até o fim, e o QueryClient que ele limparia já foi descartado.

O estrago vem do AsyncLocalStorage. O Node copia o store ativo para cada timer, e o Next.js renderiza cada requisição dentro de um store que referencia request, response e spans do OpenTelemetry. Timer pendente é raiz de GC, então cada requisição finalizada ficava presa até o disparo. A correção foi um cache de servidor que monta todas as queries com cacheTime: Infinity, o que impede o timer de começar. Os pods caíram de cerca de 4,8 GiB para cerca de 1,2 GiB. Na v4 e na v5 o padrão no servidor já é infinito, mas um gcTime finito explícito nos hooks reabre a armadilha. A issue TanStack/query#11320 estava sem correção mergeada em novembro de 2026.

Para quem opera Next.js em produção, a lição vale além do react-query: qualquer setTimeout criado durante uma requisição segura essa requisição até disparar. Bibliotecas feitas para o navegador fazem isso o tempo todo, com polling, debounce e retries. Se você usa gcTime próprio nos hooks, atualizar para a v5 não resolve sozinho. E se o autoscaling depende de memória, a correção pode reduzir réplicas e subir latência, então acompanhe esses números depois.