Un script de nettoyage exécuté sur la plateforme de publication du site a identifié par erreur des extraits de code comme étant des variables Liquid malformées et les a supprimés de tous les articles qui les contenaient. Ce bug a laissé des dizaines de publications techniques sans le code d'exemple sur lequel les lecteurs comptent, entraînant un retour en arrière (rollback) urgent et une remise en question de la manière dont les migrations de contenu sont testées.

Comment le bug s'est glissé

La plateforme utilise Liquid, un langage de templating qui balise le contenu dynamique avec des balises telles que {{ … }}. Une tâche de maintenance de routine était censée élaguer les balises isolées qui pourraient interrompre le rendu. L'analyseur du script recherchait les balises d'ouverture dépourvues de balise de fermeture correspondante et, lorsqu'il en trouvait une, supprimait tout le bloc pour « corriger » l'erreur.

En pratique, l'analyseur n'a pas reconnu les balises {% raw %} et {% endraw %} qui encadrent les blocs de code. Ces balises indiquent à Liquid de traiter tout ce qui se trouve à l'intérieur comme du texte brut, mais le script défectueux a traité la balise d'ouverture {% raw %} comme une variable non fermée ({{% raw %}) et a supprimé le code environnant. Le message d'erreur enregistré était :

Liquid syntax error: Variable '{{% raw %}' was not properly terminated.

Comme le script opérait sur le dépôt de contenu en direct, la suppression s'est produite en masse, effaçant les exemples de code de tous les articles concernés en une seule passe.

Ce qui est en jeu

Les articles techniques dépendent des extraits de code pour illustrer des concepts, reproduire des résultats et guider les lecteurs à travers des procédures étape par étape. La perte de ces blocs rend les publications largement inutiles, oblige les auteurs à réécrire le contenu et érode la confiance dans la fiabilité de la plateforme. Pour un site qui fonde sa réputation sur une documentation de haute qualité pour les développeurs, l'incident menace à la fois l'audience et la bonne volonté des contributeurs.

Les détails que la plupart des lecteurs ignorent

  • Traitement par lots sans sandboxing – Le script a été exécuté directement sur les données de production plutôt que sur une copie de staging.
  • Gestion insuffisante des balises – Seul un sous-ensemble de balises Liquid a été pris en compte ; {% raw %} a été omis de la liste blanche.
  • Manque de tests incrémentaux – La tâche a été déployée sur l'ensemble du jeu de données sans test pilote sur un petit échantillon.

Ce qui aurait pu l'empêcher

  • Exécuter les migrations sur une copie – Appliquez toute transformation massive à une version isolée (sandboxed) de la base de données au préalable.
  • Tester les analyseurs par tests unitaires avec toutes les variations de balises – Incluez les cas limites tels que les blocs raw, les balises de commentaire et les structures imbriquées.
  • Déploiement progressif – Traitez un nombre limité d'articles, vérifiez les résultats, puis passez à l'échelle.

Contre-argument

Certains soutiennent que tester chaque script sur une sauvegarde complète est peu pratique pour les sites évoluant rapidement, et que le risque de perte de données est compensé par la nécessité de correctifs rapides. Bien que la rapidité soit importante, le coût de l'annulation d'une suppression massive – tant en temps de développement qu'en dommages réputationnels – dépasse souvent le délai introduit par un déploiement prudent.

À surveiller ensuite

L'équipe a restauré le code manquant à partir des sauvegardes et révise l'outil de nettoyage pour qu'il reconnaisse toutes les constructions Liquid. Ils prévoient de publier un post-mortem détaillant le flux de travail de test