El arreglo estaba bien: el problema era que solo miraba hacia delante
Dos entradas de un blog estuvieron dos semanas y media sirviendo diagramas que devolvían 404. El arreglo ya estaba desplegado y la monitorización daba verde: ninguna de las dos cosas miraba donde debía.
Un fallo ya corregido siguió campando a sus anchas durante dos semanas y media. Dos entradas de un blog servían diagramas que devolvían 404, y ni el arreglo del publicador ni la monitorización lo detectaron. El autor ha publicado el análisis de por qué, y las dos causas que describe son un clásico de cualquier pipeline: el arreglo solo miraba hacia delante y la comprobación medía la cosa equivocada.
Un 404 de manual
Los dos posts apuntaban a su diagrama por nombre de fichero, algo terminado en -diagram.svg, sin dominio y sin barra inicial. Eso es una ruta relativa. Ghost renderiza el markdown tal cual, así que el navegador resolvía ese nombre contra la URL del propio post y pedía un fichero que nunca existió en esa dirección. El SVG vivía en el repositorio de contenido; hacer merge de un post ahí no sube nada a un CDN. La imagen y la página que la referenciaba estaban en dos mundos distintos y nada en medio se enteró.
El 26 de agosto el autor ya había cambiado el publicador: cada imagen referenciada localmente se sube a Ghost antes de enviar nada y su referencia se reescribe a la URL absoluta que devuelve el sistema. Si una imagen no se puede resolver, la publicación se rechaza en vez de salir con un agujero. El orden importa: publicar primero y reparar después no es equivalente, porque el boletín sale en el momento en que se crea el post, con lo que diga el cuerpo en ese instante. El código era correcto, estaba enganchado en las tres rutas de publicación y tenía tests. No sirvió de nada para los dos posts que estaban rotos.
El arreglo no toca lo ya publicado
Lo que protege el cambio es el acto de publicar. Nada en el pipeline revisa un post que ya salió. No es que un guardián fallara: esas dos entradas estaban fuera del conjunto de cosas que el guardián podía ver. Arreglar el bug y reparar los artefactos son dos afirmaciones distintas, y el autor confiesa que había estado tratando la primera como si implicara la segunda. Todo post nuevo desde esa fecha saldría bien; la cohorte anterior seguiría rota hasta que alguien fuera a por ella a propósito.
La segunda pata es la comprobación. Había monitorización, y las dos páginas devolvían 200. El HTML estaba bien, el texto estaba bien, el maquetado estaba bien. Lo único que fallaba era una petición posterior de la página, por un fichero que la comprobación nunca pedía. Un 200 no dice nada de las imágenes que hay dentro. El chequeo nuevo recorre cada post publicado, extrae cada imagen que referencia y pide cada una por separado; encontró los dos rotos de inmediato y ahora da cero fallos en los nueve posts.
Los diagramas vuelven a cargar, ahora desde el CDN. Lo aprovechable son dos preguntas que el autor no se hizo y que piensa hacer de serie: cuando entra un arreglo, quién está ya al otro lado y qué le llega; y cuando una comprobación da verde, exactamente qué miró.
