Résumé

  • Cloudflare a clos l’incident 238b69fw6l55 le 4 août à 07 h 12 min 40 s UTC, après l’exposition imprévue d’un objet global Temporal dans Workers.
  • Temporal.Now renvoyait le 1er janvier 1970, alors que Date et Date.now() continuaient de donner l’heure correcte.
  • Un Worker qui n’installait son polyfill qu’en l’absence d’une implémentation native pouvait ne plus l’installer et calculer silencieusement des jetons, durées de vie ou dates à partir de 1970.
  • L’incident distinct qtn3z0pny08n interdisait le déploiement de Workers et Workers for Platforms combinant nodejs_compat avec une date de compatibilité égale ou postérieure au 4 août 2026.
  • Cloudflare a proposé de retirer provisoirement nodejs_compat, puis a déclaré cet incident résolu à 03 h 03 min 00 s UTC.
  • L’entreprise n’a publié ni cause technique, ni population touchée, ni dommage client, ni mesure préventive pour l’un ou l’autre incident, et n’a pas affirmé qu’ils étaient liés.

La chronologie opérationnelle dépasse celle de la page d’état

Le premier avis a été ouvert le 3 août à 15 h 13 min 33 s UTC et clos 57 547,538 secondes plus tard. Mais Cloudflare a précisé que l’objet fautif était exposé depuis le 30 juillet. Le temps d’incident mesure donc la période de prise en charge publique, pas nécessairement toute la période pendant laquelle une application a pu produire un résultat erroné.

Cette différence est décisive pour l’enquête client. Il faut rechercher les Workers qui testaient la présence de Temporal, les versions déployées depuis le 30 juillet et les objets temporels effectivement créés. La résolution de la plateforme arrête le défaut amont; elle n’annule pas un jeton déjà émis avec une date d’expiration en 1970 ni une durée de vie déjà transmise à un autre système.

Le niveau « minor » appartient à la nomenclature de Cloudflare. Faute de nombre de Workers, de requêtes ou de clients concernés, il ne mesure pas le coût particulier d’une rotation de jetons, d’un refus d’accès ou d’un calcul commercial erroné.

Une détection de capacité a confondu présence et validité

Le mécanisme n’était pas un arrêt général de l’horloge. Date et Date.now() restaient corrects. Le problème venait de l’apparition d’une capacité que le code n’attendait pas: l’objet global indiquait qu’une implémentation native existait, mais son horloge restait bloquée à l’époque Unix.

Un polyfill conditionnel repose sur une règle simple: installer le remplacement si l’objet natif manque. Cette règle devient dangereuse quand la plateforme change la réponse sans garantir le comportement. Le Worker peut continuer à répondre, aucune exception n’est levée, et l’erreur acquiert la forme crédible d’une date calculée.

Une vérification sémantique serait plus robuste qu’un seul test d’existence. Pour une fonction sensible, l’application peut vérifier qu’un instant se situe dans une plage plausible par rapport à une autre observation, puis refuser de créer des droits ou des durées impossibles. Ce contrôle ne dispense pas Cloudflare de livrer une API correcte; il borne le dommage lorsqu’une capacité amont change silencieusement de sens.

L’autre incident s’est produit avant l’exécution

Le refus lié à nodejs_compat concernait une autre frontière. La combinaison du drapeau avec une date de compatibilité à partir du 4 août était rejetée pour Workers comme pour Workers for Platforms. Le programme n’atteignait pas le moteur d’exécution: l’assertion bloquait sa mise en production.

Cloudflare a indiqué travailler à l’assouplissement de cette assertion. Retirer le drapeau permettait d’éviter l’erreur, selon l’avis. Cela ne prouve pas que le retrait conservait toutes les API et tous les comportements nécessaires. Pour certaines applications, la recommandation pouvait être une option de diagnostic; elle ne constituait pas automatiquement un repli sûr.

Entre l’ouverture et la clôture, 4 000,289 secondes se sont écoulées. Le statut ne dit pas combien de déploiements ont été refusés, quels calendriers ont été manqués ou quelles équipes ont utilisé le contournement.

La date de compatibilité est un contrat de production

Une date de compatibilité sert à dissocier l’évolution de la plateforme de l’adoption immédiate par chaque client. Elle donne à une équipe la possibilité de choisir un ensemble de comportements, de le tester et de le conserver pendant une migration. Dès lors, elle appartient au dispositif d’exploitation autant qu’à la documentation.

L’incident du 4 août montre ce qui arrive si la matrice « date plus drapeaux » n’est pas testée comme un produit. Chaque option peut fonctionner isolément et la combinaison échouer au moment du déploiement. Le test pertinent n’est pas seulement une compilation; c’est une mise en production de canari avec les mêmes paramètres que le service réel.

Pour conserver une issue réversible, une équipe peut garder une date connue comme bonne, documenter les dépendances exactes à nodejs_compat et tester les dates futures avant la fenêtre de livraison. Il s’agit d’une capacité de reprise, non d’un transfert de responsabilité pour l’assertion défectueuse.

Les deux défaillances appellent deux canaris

La proximité de calendrier invite à étudier la gouvernance des versions. Elle n’autorise pas à écrire qu’une même livraison ou qu’une même erreur interne a provoqué les deux incidents. Cloudflare ne l’a pas établi.

Le canari du moteur d’exécution doit vérifier des invariants observables: temps plausible, création et expiration de jetons, calcul de durées. Le canari du plan de contrôle doit exercer les configurations de déploiement à venir, notamment les couples de date et de drapeau. Un simple test HTTP vert ne voit ni la sémantique temporelle fausse ni une livraison refusée avant d’atteindre la production.

Cette séparation aide aussi à attribuer les responsabilités. La plateforme doit corriger l’exposition de l’API et l’assertion. Le client doit identifier les artefacts aval et choisir un repli testé. Aucun des deux volets ne remplace l’autre.

Les inconnues empêchent encore de mesurer le risque

Cloudflare n’a pas indiqué la cause racine, le chemin de mise en production, les essais manquants ou les changements de contrôle adoptés après résolution. On ignore aussi combien de Workers avaient abandonné leur polyfill, combien de déploiements ont été refusés et si les erreurs citées se sont traduites par des dommages.

Les exemples—jeton émis à l’instant zéro, expiration en 1970, TTL et calculs de date erronés—décrivent des mécanismes possibles. Ils ne forment pas un inventaire de conséquences constatées. De même, la clôture du second incident confirme que le refus a cessé selon Cloudflare, mais pas que chaque application a remis son drapeau, sa date ou sa livraison dans l’état voulu.

La prochaine étape crédible associerait la cause à un contrôle vérifiable: test de sémantique avant exposition d’un global, matrice de configurations avant activation d’une date, seuil de détection et procédure de retour arrière.

Sources