要約

  • Cloudflare は8月4日07時12分40秒（UTC）、Workers に意図しないグローバルTemporalオブジェクトが公開されたインシデント238b69fw6l55を解決した。
  • Temporal.Nowは1970年1月1日を返したが、DateとDate.now()は正しい時刻を返していた。
  • ネイティブ実装がない場合だけ polyfill を入れる Worker では、polyfill が入らなくなり、トークン、TTL、日付計算が1970年を基準に無警告で実行される可能性があった。
  • 別のqtn3z0pny08nでは、nodejs_compatと2026年8月4日以降の互換日付を使う Workers および Workers for Platforms の配備が拒否された。
  • Cloudflare は一時的な回避策としてnodejs_compatの削除を案内し、この配備障害を03時03分00秒（UTC）に解決した。
  • いずれについても技術的根本原因、影響数、顧客損失、再発防止策は示されず、二件が関連するとの説明もない。

まず確認すべきは、どの段階で状態が変わったかだ

実行時インシデントでは、公開状態そのものが変わった。従来は存在しなかったはずのTemporalが見えるようになり、アプリケーションの機能検出が別の分岐を選んだ。ところが、その時計は Unix エポックに固定されていた。

配備インシデントでは、実行状態に到達していない。指定されたフラグと互換日付を持つ構成が制御面で拒否された。したがって、二件を同じ「Workers が止まった」という表現でまとめると、復旧条件を取り違える。

前者の復旧には、プラットフォーム修正だけでなく、誤った時刻で作られた成果物の確認が必要である。後者では、拒否された版を再配備し、回避策を使った場合は必要な互換動作が残っているかを確かめなければならない。

エラーが出ない時間異常は下流に残る

Cloudflare によると、Temporalを使った処理はエラーを出さずに進むことがあった。発行時刻がゼロのトークン、1970年に失効するトークン、誤った TTL や日付演算が例として挙げられた。

これは、可用性監視だけでは見つけにくい。Worker が HTTP 応答を返し続ければ、外形監視は正常と判断し得る。異常は認証、キャッシュ、予約処理、並べ替えなど、時刻の意味を使う下流で初めて表面化する可能性がある。

ただし、例は実害の集計ではない。Cloudflare は何件の誤トークンや誤 TTL が実際に生じたかを公表していない。またDateとDate.now()は正常であり、すべての Worker が影響したわけでもない。

公開タイムラインより前を調べる必要がある

実行時インシデントの公開ライフサイクルは、8月3日15時13分33秒から翌日07時12分40秒までの57,547.538秒だった。しかし、Cloudflare は意図しないグローバルが7月30日から公開されていたと説明した。

顧客の調査期間は、ステータスページの開始時刻ではなく、その7月30日まで遡る必要がある。該当期間の配備版、polyfill の分岐、異常なタイムスタンプ、拒否された資格情報やキャッシュ状態を追うべきだ。

解決時刻も、顧客側の復旧時刻とは限らない。プラットフォームが正常化しても、既に発行したデータの無効化、再計算、再配備が終わるまでは影響が残る。

nodejs_compatを外す判断には依存関係表が要る

配備障害は01時56分19秒から03時03分00秒（UTC）まで4,000.289秒続いた。Cloudflare はアサーションを緩和するとし、エラーを避けるためにnodejs_compatを外すよう案内した。

この案内を一般的な安全策とみなすことはできない。フラグが有効にする API や挙動をアプリケーションが必要としていれば、削除によって別の実行時障害が起こり得る。回避策を選べるのは、その依存関係と試験結果が分かっている場合である。

運用チームは、各フラグを必要とする理由、最後に確認済みの互換日付、配備可能なロールバック構成を記録しておく必要がある。これは Cloudflare の責任を薄めるものではなく、障害時の選択肢を実在させる作業だ。

互換日付は将来を先に試すための境界でもある

互換日付は、プラットフォームの変化をすべての顧客に同時適用しないための仕組みである。そのため、日付とフラグの組み合わせは本番契約の一部になる。

顧客側では、次の互換日付を本番日より前に canary へ適用し、実際のフラグ構成で配備できるかを継続的に試せる。Cloudflare 側では、単独のフラグだけでなく、代表的な日付・フラグ・製品経路の組み合わせを検証する必要がある。

一方、Temporalには別の canary が要る。オブジェクトの有無ではなく、現在時刻が妥当な範囲にあるか、発行と失効の不変条件を満たすかを確かめる。二種類の試験は障害点が違うため、統合できない。

同日に終わったことは、同じ原因の証拠ではない

二件は Workers の変更に関係し、同じ8月4日に解決した。リリースの段階化、試験、ロールバックを横断的に検証する理由にはなる。しかし、一つのリリースや一つの欠陥が両方を生んだと断定する根拠にはならない。

実行時側で問うべきは、なぜ意図しない能力が公開され、誤った時計が意味試験を通ったのかである。配備側では、なぜ有効と考えられる構成がアサーションに拒まれたのかを問う。Cloudflare が後に共通経路を示すまでは、原因の線を別々に保つ方が再発防止を具体化できる。

情報源