Post-mortem: doce días desplegando una web rota sin saberlo
Del 29 de junio al 11 de julio esta web no se desplegó ni una sola vez, y yo convencido de que sí. La historia completa del límite de 3 MB de Cloudflare, cómo lo encontré, cómo lo arreglé y las tres lecciones que me llevo.
Esta web corre en un Worker de Cloudflare, en el plan gratuito. Ese plan tiene una regla que yo conocía de leerla en la documentación y que no me había parado a respetar: el código del worker no puede superar los 3 MB comprimidos. El 29 de junio añadí una página que contaba tokens usando una librería que pesa 3,6 MB. El worker pasó del límite y cada deploy empezó a fallar. Yo no me enteré hasta el 11 de julio.
Cómo se esconde un fallo durante doce días. Muy fácil: desplegaba a mano, el comando devolvía un error largo que terminaba en un código poco legible, y la web seguía online — sirviendo la versión del día 28. Como la portada cargaba y yo casi siempre probaba cosas en local, todo parecía correcto. Publiqué artículos, retoqué páginas y arreglé un formulario durante casi dos semanas, y nada de eso llegó a producción. La web rota no se veía rota: se veía vieja, que es mucho peor, porque nadie te avisa.
Cómo apareció. Arreglando el formulario de contacto, quise comprobar en producción que el cambio estaba desplegado. No estaba. Ahí sí leí el error entero, de arriba abajo, y la penúltima línea lo decía claro: el script comprimido pesaba 3,25 MB y el máximo eran 3. No era un fallo del formulario: era todo el deploy, desde hacía doce días.
El diagnóstico. Con el tamaño del worker desglosado, el culpable saltó a la vista: la librería de contar tokens entraba entera en el bundle del servidor, aunque solo se usaba en el navegador. Y de regalo encontré otra igual: la librería de 3D que anima las escenas de fondo también estaba en el servidor sin pintar nada allí. La solución fue partir cada página en dos ficheros — uno de servidor que no importa nada pesado, y otro de cliente que se carga solo en el navegador — y el worker bajó de 3,25 a 1,68 MB. La mitad del peso que tenía no hacía nada.
Lección 1: un deploy que puede fallar en silencio, fallará en silencio. Ahora el deploy lo hace un robot en cada push, y si falla lo veo en rojo en GitHub en vez de tener que acordarme de leer una terminal. Desde esta semana además hay una batería de tests que navega la web recién construida antes de permitir el despliegue: si algo básico se rompe, el deploy ni se intenta.
Lección 2: mide lo que tiene un límite. El peso del worker tiene un tope duro, así que ahora se comprueba en cada build y está a la vista en la página del proyecto. Cualquier cosa con un límite duro y crecimiento silencioso — un bundle, una cuota, un disco — acaba chocando; la única pregunta es si te enteras tú antes que el límite.
Lección 3: los errores se leen enteros. La información estuvo ahí desde el primer día, en la penúltima línea de un error que yo no leía porque era largo y porque "la web funcionaba". Me habría ahorrado doce días con treinta segundos de atención. De todo lo que me llevo de este fallo, esto es lo que más me está costando aprender de verdad.
