Un script de limpieza ejecutado en la plataforma de publicación del sitio identificó erróneamente fragmentos de código como variables de Liquid malformadas y los eliminó de cada artículo que los contenía. El fallo dejó decenas de publicaciones técnicas sin el código de ejemplo en el que confían los lectores, lo que provocó una reversión urgente y un replanteamiento de cómo se prueban las migraciones de contenido.

Cómo se filtró el error

La plataforma utiliza Liquid, un lenguaje de plantillas que marca contenido dinámico con etiquetas como {{ … }}. Se suponía que una tarea de mantenimiento rutinaria debía podar etiquetas sueltas que pudieran romper el renderizado. El analizador del script buscaba etiquetas de apertura que carecieran de una etiqueta de cierre correspondiente y, cuando encontraba una, eliminaba todo el bloque para "corregir" el error.

En la práctica, el analizador no reconoció las etiquetas {% raw %} y {% endraw %} que envuelven los bloques de código. Esas etiquetas le indican a Liquid que trate todo lo que hay en su interior como texto literal, pero el script defectuoso trató la apertura {% raw %} como una variable sin cerrar ({{% raw %}) y eliminó el código circundante. El mensaje de error registrado fue:

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

Debido a que el script operaba sobre el repositorio de contenido en vivo, la eliminación ocurrió de forma masiva, borrando los ejemplos de código de todos los artículos afectados en una sola pasada.

Lo que está en juego

Los artículos técnicos dependen de fragmentos de código para ilustrar conceptos, reproducir resultados y guiar a los lectores a través de procedimientos paso a paso. Perder esos bloques hace que las publicaciones sean en gran medida inútiles, obliga a los autores a reescribir el contenido y erosiona la confianza en la fiabilidad de la plataforma. Para un sitio que construye su reputación sobre documentación de alta calidad para desarrolladores, el incidente amenaza tanto la audiencia como la buena voluntad de los colaboradores.

Los detalles que la mayoría de los lectores pasan por alto

  • Procesamiento por lotes sin sandboxing – El script se ejecutó directamente sobre los datos de producción en lugar de una copia de staging.
  • Gestión insuficiente de etiquetas – Solo se tuvo en cuenta un subconjunto de etiquetas de Liquid; {% raw %} fue omitida de la lista de permitidas (whitelist).
  • Falta de pruebas incrementales – La tarea se implementó en todo el conjunto de datos sin una ejecución piloto en una muestra pequeña.

Qué podría haberlo evitado

  • Ejecutar las migraciones en una copia – Aplicar cualquier transformación masiva primero a una versión aislada (sandboxed) de la base de datos.
  • Realizar pruebas unitarias de los analizadores contra todas las variaciones de etiquetas – Incluir casos límite como bloques raw, etiquetas de comentario y estructuras anidadas.
  • Implementación gradual – Procesar un número limitado de artículos, verificar los resultados y luego escalar.

Contrapunto

Algunos argumentan que probar cada script en una copia de seguridad completa es poco práctico para sitios de ritmo rápido, y que el riesgo de pérdida de datos se ve superado por la necesidad de correcciones rápidas. Si bien la velocidad es importante, el coste de deshacer una eliminación masiva —tanto en tiempo de desarrollo como en daño reputacional— a menudo supera el retraso introducido por una implementación cautelosa.

Qué esperar a continuación

El equipo ha restaurado el código faltante mediante copias de seguridad y está revisando la herramienta de limpieza para que reconozca todas las construcciones de Liquid. Planean publicar un post-mortem detallando el flujo de trabajo de pruebas actualizado y compartir el script revisado públicamente para que otros editores puedan evitar el mismo error. El incidente sirve como recordatorio: incluso un pequeño error de análisis puede borrar semanas de esfuerzo de los autores, haciendo que las pruebas rigurosas sean innegociables.