Resumen

  • Cloudflare resolvió a las 07:12:40 UTC del 4 de agosto el incidente 238b69fw6l55, causado por la exposición no prevista de un objeto global Temporal en Workers.
  • Temporal.Now informaba del 1 de enero de 1970, mientras Date y Date.now() seguían dando la hora correcta.
  • Los Workers que solo instalaban un polyfill cuando no detectaban una implementación nativa podían omitirlo y calcular silenciosamente tokens, TTL o fechas contra 1970.
  • El incidente separado qtn3z0pny08n rechazó despliegues de Workers y Workers for Platforms con nodejs_compat y fecha de compatibilidad igual o posterior al 4 de agosto de 2026.
  • Cloudflare recomendó retirar temporalmente nodejs_compat para evitar el rechazo y declaró resuelto ese incidente a las 03:03:00 UTC.
  • La empresa no publicó causa raíz, alcance, daño, cambios preventivos ni relación causal entre ambos incidentes.

La cadena falló primero al interpretar una capacidad

Muchas aplicaciones toman una decisión binaria al arrancar: si una API existe, usan la versión nativa; si no, cargan un polyfill. La exposición inesperada de Temporal cambió esa decisión sin ofrecer un comportamiento válido. El Worker podía concluir que ya no necesitaba su sustituto probado y adoptar una implementación cuyo reloj permanecía en el origen de Unix.

El peligro estaba en la apariencia de normalidad. Cloudflare dijo que no se generaba ningún error. El código seguía ejecutándose y podía producir un token con instante de emisión cero, una expiración en 1970, un TTL equivocado o aritmética temporal incorrecta. Un fallo explícito habría detenido la operación; este podía propagarse como dato aparentemente válido.

No afectó a Date ni a Date.now(). Tampoco hay evidencia de que todo Worker usara Temporal. El perímetro dependía de la detección condicional, del polyfill y de la lógica temporal concreta de cada aplicación.

Después falló la puerta de despliegue

El segundo incidente se encontraba antes del runtime. Una aserción no permitía desplegar Workers con el indicador nodejs_compat cuando la fecha de compatibilidad era el 4 de agosto de 2026 o posterior. También alcanzó a Workers for Platforms.

Cloudflare indicó que iba a relajar la aserción y propuso quitar el indicador para esquivar el error. Esa instrucción permitía probar una ruta alternativa, pero no garantizaba equivalencia. Una aplicación que requiera APIs o comportamientos de compatibilidad con Node.js puede desplegar sin el indicador y fallar después de una forma distinta.

El ciclo público duró 4.000,289 segundos. No se conoce el número de versiones bloqueadas, clientes afectados, regiones implicadas ni ventanas de cambio perdidas.

El control pertenece a varios eslabones

En un servicio serverless, el proveedor controla el runtime y el plano de despliegue; el cliente controla el código, las fechas elegidas, los indicadores y la verificación de sus resultados. Los incidentes muestran que ninguno de esos eslabones, por separado, constituye una garantía completa.

Cloudflare debe asegurar que una API expuesta cumple su semántica y que las combinaciones documentadas pueden desplegarse. El cliente necesita saber qué depende de cada capacidad, conservar configuraciones reversibles y detectar salidas imposibles. Eso no convierte un defecto del proveedor en culpa del usuario. Reduce el tiempo entre un cambio externo y una respuesta informada.

La asignación también continúa después de la resolución. Cloudflare puede reparar el runtime; solo el cliente conoce los tokens, cachés, sesiones o cálculos que salieron de su aplicación durante la exposición.

Una prueba verde de disponibilidad no habría bastado

Un monitor que invoque una URL y espere respuesta podría haber considerado sano el Worker con hora incorrecta. Y no habría visto un despliegue rechazado hasta que el pipeline intentara usar la combinación nueva. La observabilidad debe comprobar el comportamiento que el negocio necesita, no solo la presencia del proceso.

Para Temporal, un canario puede comparar la hora con un rango plausible y probar emisión y expiración. Para las fechas de compatibilidad, un entorno previo puede desplegar periódicamente con la próxima fecha y con los mismos indicadores de producción. Son pruebas distintas porque los puntos de fallo son distintos.

También conviene fijar límites: rechazar fechas imposibles en operaciones sensibles, mantener una fecha de compatibilidad conocida y documentar por qué se activa nodejs_compat. Sin ese inventario, un workaround rápido puede eliminar una dependencia que nadie sabía que existía.

La fecha operativa no empieza ni termina con el aviso

El incidente de runtime estuvo abierto 57.547,538 segundos, pero Cloudflare afirmó que el global llevaba expuesto desde el 30 de julio. Por tanto, la investigación de datos debe comenzar antes de la apertura del aviso. La fecha de resolución tampoco limpia automáticamente los artefactos emitidos durante el periodo.

En el incidente de despliegue, la resolución indica que Cloudflare dejó de considerar activo el problema. No demuestra que cada equipo reintentara su versión, restaurara el indicador o verificara el resultado del workaround.

La métrica más útil para un cliente no es el tiempo de la página de estado. Es el intervalo entre la primera salida incorrecta o el primer despliegue rechazado y la recuperación verificada de su propio servicio.

La proximidad no prueba una raíz común

Ambos incidentes pertenecen a Workers, involucran cambios de plataforma y terminaron el 4 de agosto. Es razonable que Cloudflare y sus clientes examinen cómo prueban y escalonan las versiones. No es razonable afirmar, sin evidencia, que una sola publicación, equipo o error los causó.

Mantenerlos separados mejora el análisis. El primero exige saber por qué apareció una capacidad no prevista con estado incorrecto. El segundo, por qué una matriz de configuración válida activó una aserción. Si después Cloudflare publica un vínculo técnico, podrá incorporarse. Hasta entonces, una causa inventada ocultaría las medidas específicas que cada fallo requiere.

Fuentes