Resumo

  • A Cloudflare resolveu às 07:12:40 UTC de 4 de agosto o incidente 238b69fw6l55, em que o runtime de Workers expôs um objeto global Temporal que não deveria estar disponível.
  • Temporal.Now retornava 1º de janeiro de 1970, enquanto Date e Date.now() continuavam corretos.
  • Workers que só instalavam um polyfill na ausência de implementação nativa podiam deixar de instalá-lo e calcular tokens, TTLs ou datas silenciosamente contra 1970.
  • O incidente separado qtn3z0pny08n impediu implantações de Workers e Workers for Platforms com nodejs_compat e data de compatibilidade em ou após 4 de agosto de 2026.
  • A Cloudflare orientou a remoção temporária de nodejs_compat para evitar o erro e resolveu esse incidente às 03:03:00 UTC.
  • A empresa não divulgou causa técnica, escala afetada, dano ao cliente, prevenção futura nem uma relação causal entre os dois casos.

O risco operacional estava na decisão silenciosa do código

O padrão “se existe, use” economiza complexidade quando uma plataforma adiciona uma API nativa correta. No incidente de Temporal, a existência do objeto alterou a decisão do Worker, mas não preservou a expectativa do aplicativo. O relógio permanecia no epoch Unix.

Um polyfill condicional poderia, por isso, parar de ser carregado. O restante do código continuaria executando e receberia valores formalmente válidos, porém semanticamente impossíveis. A Cloudflare citou tokens emitidos no instante zero e expirados em 1970, TTLs incorretos e aritmética de datas errada.

Não se deve ampliar o perímetro. Date e Date.now() continuaram certos, e o problema dependia do uso de Temporal, do teste de presença e da lógica temporal do Worker. Também não há contagem pública de quantos exemplos se transformaram em dano real.

O tempo do cliente começou antes do tempo do incidente

A página de status abriu o caso às 15:13:33 UTC de 3 de agosto e o encerrou 57.547,538 segundos depois. A própria Cloudflare, contudo, disse que o objeto estava exposto desde 30 de julho. A janela de auditoria do cliente precisa começar nessa data anterior.

É necessário identificar versões em execução, decisões de polyfill, credenciais ou sessões rejeitadas, itens de cache com duração anormal e cálculos persistidos. Corrigir o relógio na plataforma não revoga automaticamente um token já emitido nem refaz uma data já gravada.

Por isso, o tempo de recuperação do fornecedor e o tempo de recuperação do cliente não são iguais. O segundo termina apenas quando a organização verifica os efeitos posteriores e corrige o que for necessário.

A segunda falha bloqueou a mudança antes da produção

No incidente de implantação, a combinação de nodejs_compat com uma data igual ou posterior a 4 de agosto foi recusada. O alcance declarado incluía Workers e Workers for Platforms. Não era um comportamento incorreto depois do deploy; era a impossibilidade de chegar ao runtime com aquela configuração.

A Cloudflare disse que relaxaria a asserção e sugeriu retirar o sinalizador. Essa orientação era um desvio temporário, não uma prova de equivalência. Se a aplicação dependesse das APIs ou do comportamento de compatibilidade com Node.js, remover o sinalizador poderia criar outro defeito depois da implantação.

O ciclo durou 4.000,289 segundos. Não foram informados o número de releases rejeitados, regiões, clientes, janelas perdidas ou efeitos do workaround.

Recuperação exige saber o que cada sinalizador protege

Uma equipe só consegue avaliar a remoção de nodejs_compat se tiver um inventário de dependências. O nome do sinalizador não diz quais módulos, APIs ou diferenças de runtime são essenciais para aquele Worker.

Esse inventário deve ligar cada flag a testes, manter uma última data de compatibilidade validada e registrar uma configuração de rollback que ainda possa ser implantada. Em uma emergência, isso permite escolher entre esperar a correção, voltar a uma data anterior ou usar um caminho alternativo testado.

Nada disso transfere ao cliente a responsabilidade pela asserção defeituosa. A Cloudflare controla o plano de implantação. A disciplina do cliente reduz a incerteza sobre as próprias consequências enquanto o fornecedor repara esse plano.

Um monitor de disponibilidade não cobre o contrato

O Worker com hora de 1970 podia responder normalmente. Um teste HTTP simples poderia continuar verde. Já a regressão de compatibilidade só aparecia quando o pipeline tentava implantar uma combinação futura.

São necessários dois canários. O de runtime verifica invariantes do negócio—hora plausível, emissão anterior à expiração, TTL positivo. O de controle tenta implantar antecipadamente a próxima data com os mesmos sinalizadores e o mesmo caminho de produto usado em produção.

A plataforma também precisa dos dois. Testar a existência de um objeto sem testar sua semântica é insuficiente; testar flags isoladas sem a matriz de datas também é.

Coincidência temporal não fecha a causalidade

Os incidentes pertencem a Workers, envolvem releases e foram encerrados em 4 de agosto. Isso justifica uma revisão conjunta da governança de mudanças. Não justifica afirmar que uma única versão, equipe ou falha os causou.

O caso de runtime requer explicação sobre exposição de capacidade, inicialização do relógio e testes semânticos. O caso de implantação requer explicação sobre a asserção e a cobertura da matriz data + flag. Preservar essa separação é mais útil do que preencher a lacuna com uma causa não publicada.

Se a Cloudflare demonstrar depois um elo técnico, o diagnóstico poderá ser atualizado. Até lá, o ponto comum é de controle: uma mudança de plataforma deve ser testada tanto na entrada quanto no resultado.

Fontes