摘要

  • Cloudflare 于 8 月 4 日 07:12:40 UTC 解决事件238b69fw6l55；最新 Workers Runtime API 曾意外暴露全局Temporal对象。
  • Temporal.Now返回 1970 年 1 月 1 日，而Date与Date.now()仍然返回正确时间。
  • 仅在没有原生Temporal时安装 polyfill 的 Worker 可能因此跳过 polyfill，并悄无声息地按 1970 年计算令牌、TTL 或日期。
  • 另一起事件qtn3z0pny08n拒绝部署使用nodejs_compat且兼容日期为 2026 年 8 月 4 日或更晚的 Workers 与 Workers for Platforms。
  • Cloudflare 一度建议删除nodejs_compat以绕过部署错误，并在 03:03:00 UTC 宣布该事件解决。
  • Cloudflare 没有披露两起事件的技术根因、受影响规模、客户损失、预防措施，也没有说它们存在共同原因。

一项“存在”的能力，不一定是一项“可用”的能力

不少应用用一个简单分支选择实现：检测到原生对象就直接使用，否则加载 polyfill。这个模式把“对象存在”当成“语义正确”。Cloudflare 这次改变了分支结果，却没有提供一个时间正确的实现。

因此，受影响的 Worker 不一定报错或停止响应。它可能照常生成一个结构完整的令牌，只是签发时间为零、到期时间落在 1970 年；也可能算出错误 TTL 或日期差。显性故障会触发告警，形状正确的错误数据却可能一路进入认证、缓存或业务系统。

影响边界不能扩大。Cloudflare 明确说Date与Date.now()正确；并非所有 Worker 都使用Temporal，也并非所有使用者都通过“缺失时才加载”的条件安装 polyfill。

平台修复以后，错误产物仍需客户清点

该事件从 8 月 3 日 15:13:33 UTC 开启，到 8 月 4 日 07:12:40 UTC 解决，公开生命周期为 57,547.538 秒。但 Cloudflare 说错误全局对象自 7 月 30 日起已经暴露。客户的核查起点因此不能只取状态页的开启时间。

需要查的是可观察产物：哪些版本在 7 月 30 日以后运行，哪些 Worker 命中过条件分支，是否出现不可能的时间戳、令牌拒绝、缓存提前或延后失效、日期排序异常。平台把时钟修正，不会自动撤销已经签发的令牌或重算下游数据。

Cloudflare 把影响级别标为“minor”，但没有提供 Worker、请求或客户数量。对某个客户而言，影响大小取决于错误时间进入了哪条控制链，而不是状态页标签本身。

另一场故障卡在代码运行之前

部署事件的作用位置不同。带有nodejs_compat、兼容日期为 8 月 4 日或更晚的配置被断言拒绝，Workers for Platforms 也在范围内。这里不是代码上线后行为改变，而是发布控制面不让该组合上线。

Cloudflare 表示会放宽断言，并建议移除标志来避免错误。这个办法可以作为临时诊断路径，却不能被写成普遍安全的回退。应用若依赖 Node.js 兼容 API 或行为，删除标志可能把一个可见的部署失败换成更隐蔽的运行时差异。

这起事件从 01:56:19 到 03:03:00 UTC，持续 4,000.289 秒。被拒绝的部署数、受影响地区、错过的发布窗口及临时处理后果均未披露。

兼容日期其实是生产合同

兼容日期的价值，是让平台可以演进，同时让客户锁定一组已经测试的行为。它不是装饰性元数据，而是构建、发布、回滚与故障复现共同依赖的接口。

8 月 4 日的断言说明，只测试单个标志不够。真正进入生产的是“日期、标志、产品形态”组合。平台需要覆盖代表性矩阵；客户则可在正式窗口之前，用下一兼容日期和真实标志做小规模部署演练。

客户还应保留最后一个已验证日期，并写清每个标志保护的具体依赖。这样遇到控制面回归时，团队知道能退到哪里，也知道哪些标志不能随意删除。这是恢复能力，不是替平台承担缺陷责任。

两个故障需要两类探针

HTTP 可达性检查可能把时间错误的 Worker 判为健康，因为进程仍然回答。普通运行时监控也不会提前发现一个尚未尝试的新兼容日期被部署入口拒绝。

第一类探针要验证语义，例如时间是否落在合理区间、令牌签发与到期是否满足不变量、TTL 是否为正。第二类探针要验证发布合同，提前尝试未来日期、相同标志与 Workers for Platforms 路径。两者不能互相替代。

对关键业务，还可以在输出端拒绝明显不可能的日期。这个保护不是宣告Date.now()永远可信，而是让应用对自身依赖的时间语义设置最低校验。

相邻发生，不等于同一根因

两起事件都属于 Workers、都涉及平台发布，也都在 8 月 4 日关闭。这足以要求审视 Cloudflare 的发布节奏、测试覆盖与回滚设计，却不足以认定是同一次发布或同一个团队造成。

强行合并根因反而会模糊控制面。运行时事件要回答为何错误能力被暴露、为何时钟初始化错误、为何语义测试未拦截；部署事件要回答为何指定日期与标志组合触发断言、矩阵测试为何未发现。

如果 Cloudflare 以后公布共同技术链，结论可以更新。在此之前，最可靠的写法是保持两条证据链独立，只把“发布合同需要端到端验证”作为共同的分析层。

来源