Pular para conteúdo

Cache do painel e tela em branco

O incidente

Em 14/10/2026, após um deploy de produção, a landing funcionava e os pods estavam disponíveis, mas /login exibia uma tela em branco. O navegador recebia HTML em cache no endereço de um arquivo JavaScript e rejeitava o módulo pelo MIME text/html.

Durante um rollout, o HTML de uma versão pode solicitar um arquivo novo a um pod antigo. O fallback SPA anterior devolvia index.html mesmo para um asset inexistente. O Cloudflare armazenou essa resposta sob a URL do JavaScript. Isso não era detectado pelo /health do gateway, que continuava respondendo normalmente.

Correção no servidor

  • /panel-assets/ só serve arquivos reais; inexistentes retornam 404 com Cache-Control: no-store.
  • HTML e respostas padrão recebem no-store para evitar conservar referências de releases anteriores.
  • Assets existentes e versionados por hash recebem cache longo e immutable.
  • O fallback de rotas da SPA permanece para páginas como /login.

Isso impede que um asset ausente seja tratado como HTML válido e armazenado como bundle. Não torna o rollout uma troca atômica: durante a transição ainda pode haver uma requisição a arquivo ausente, e disponibilidade contínua exige avaliar a estratégia de distribuição de versões/assets.

Verificação na esteira

check-panel-assets.sh consulta /health e /login, extrai JavaScript/CSS do HTML e baixa os arquivos com GET e compressão de navegador. Confere MIME, rejeita HTML entregue como asset e exige 404 sem cache para um arquivo inexistente.

Deploy e verificação de estabilidade usam esse teste internamente e também no domínio público quando a verificação pública está habilitada. Uma falha pública pode ocorrer depois que os workloads já foram atualizados; a pipeline sinaliza o problema, mas não executa rollback automático.

O job panel_assets_tests testa Nginx em container descartável e reproduz HTML no lugar do JavaScript para garantir que o smoke test rejeite a regressão. panel_unit_tests valida testes e build do frontend quando ele muda.

Regra temporária do Cloudflare

A mitigação aplicada pelo operador ignora cache apenas neste filtro:

(http.host eq "flow.ecomsmart.com.br" and starts_with(http.request.uri.path, "/panel-assets/"))

Com Cache eligibility → Bypass cache, manter a regra depois das demais regras correspondentes. Ela afeta somente assets do painel nesse hostname; não desativa cache de outros sistemas.

Manter a mitigação até publicar e validar a correção. Antes de removê-la:

  1. Conferir deploy e verificação de estabilidade da versão corrigida.
  2. Conferir que arquivos inexistentes retornam 404/no-store e HTML retorna no-store.
  3. Revisar regras que forçam cache/TTL, pois elas podem sobrepor a política da origem.
  4. Limpar cópias problemáticas específicas, se existirem; não usar limpeza global de toda a zona como primeira opção.
  5. Remover a mitigação em uma janela acompanhada, conferir login em navegador novo e observar os próximos rollouts.

Limpar cache não substitui a correção do fallback. Cache do navegador também pode conservar uma resposta já baixada; testar em um perfil novo ajuda a separar os dois casos.

Referências: Cache Rules e ordem de aplicação.