El bug que se escondió semanas en producción: React 19, CI y el caché mal configurado
Imagina este escenario: tu equipo actualiza React 18 a React 19, el pipeline de CI termina más rápido que nunca, todos festejan... y dos semanas después producción empieza a crashear sin explicación aparente. Este es exactamente el tipo de bug que más daño hace: el que llega disfrazado de buenas noticias.
Google for Developers publicó un reto técnico corto que resume este problema de forma brillante. Y aunque parece un ejercicio académico, este patrón ocurre con más frecuencia de lo que los equipos de desarrollo en Perú y Latinoamérica quisieran admitir. Vamos a desarmarlo por completo.
En este artículo vas a entender por qué un CI más rápido puede ser una señal de peligro, cómo el caché mal configurado destruye deployments, y qué deberías revisar hoy mismo en tu pipeline.
¿Por qué el CI más rápido fue la primera señal de alerta?
En un pipeline de integración continua bien configurado, una actualización mayor de dependencias debería provocar una reconstrucción completa. Si React 19 cambió la estructura interna del build output — y lo hizo — entonces el tiempo de compilación debería ser similar o mayor al anterior, no menor.
Cuando el CI termina sorprendentemente rápido después de un cambio significativo, la explicación más probable es que no recompiló nada. Reutilizó artefactos del caché. Y si esos artefactos corresponden a React 18, lo que llega a producción es una mezcla inconsistente: código nuevo que intenta ejecutarse sobre binarios viejos.
La causa raíz, según el reto de Google for Developers, es la opción A: la clave de caché es demasiado amplia. Una clave que solo incluye el nombre del paquete ("react") sin considerar la versión exacta o el contenido del lockfile va a reutilizar el caché aunque hayas cambiado de versión mayor.
Cómo funciona el caché en CI y dónde se rompe
Los sistemas de CI como GitHub Actions, GitLab CI o CircleCI permiten guardar carpetas como node_modules entre ejecuciones para ahorrar tiempo. La lógica es simple: si las dependencias no cambiaron, no las reinstales. Tiene todo el sentido del mundo.
El problema aparece cuando la clave que define "nada cambió" está mal diseñada. Si tu clave de caché es algo como node-modules-${{ runner.os }} sin incluir el hash del package-lock.json o el yarn.lock, entonces para el sistema de caché la instalación de React 18 y React 19 son indistinguibles. Ambas viven bajo la misma clave. El caché anterior gana.
Una clave correcta debería verse así:
node-modules-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}
Con esta estructura, cualquier cambio en el lockfile — incluyendo una actualización de versión mayor — genera una clave nueva, invalida el caché anterior y fuerza una instalación limpia. Así es como debería funcionar siempre.
Por qué esto es especialmente peligroso en equipos de LATAM
En muchos equipos de desarrollo en Perú y Latinoamérica, la configuración del pipeline de CI fue hecha una vez, hace meses o años, por alguien que ya no está en el equipo. Nadie la revisa porque "siempre funcionó". Y tiene sentido: si el sistema nunca dio problemas, ¿para qué tocarlo?
El riesgo real aparece cuando el proyecto crece, las dependencias evolucionan y ese pipeline heredado empieza a tomar decisiones silenciosas que nadie nota. Un build verde no significa un build correcto. Significa que el sistema no encontró errores en lo que evaluó — pero si evaluó artefactos viejos, el resultado es inútil.
Adicionalmente, en proyectos con equipos pequeños o sin un DevOps dedicado, es común que las actualizaciones de dependencias se hagan rápido, sin revisar el impacto en la infraestructura de CI. El resultado es exactamente el escenario descrito: semanas de bugs en producción que nadie puede explicar.
¿Cómo aplica esto en tu empresa?
Si tu empresa tiene aplicaciones web en producción con pipelines de CI configurados, aquí hay tres acciones concretas que puedes revisar esta semana:
- Audita tus claves de caché: Busca en tus archivos de configuración de CI dónde defines el caché de node_modules o dependencias equivalentes. Verifica que la clave incluya el hash del lockfile, no solo el nombre del sistema operativo o del proyecto.
- Establece una política de caché limpio en actualizaciones mayores: Cada vez que el equipo actualice una dependencia de versión mayor (como React 18 → 19), el primer build debería forzar una instalación limpia. Esto puede configurarse con un flag manual o un step condicional en el pipeline.
- No confíes en el tiempo de build como indicador de éxito: Un CI que termina en la mitad del tiempo habitual después de un cambio grande no es eficiencia — es una señal de que algo no se ejecutó. Agrega validaciones explícitas que confirmen qué versiones están instaladas antes del deploy.
Estas son medidas de bajo costo que pueden evitar horas de debugging en producción y, más importante, proteger la experiencia de tus usuarios finales.
Conclusión
Un pipeline de CI que termina más rápido después de una actualización mayor no siempre es una victoria. A veces es el sistema diciéndote, en silencio, que tomó un atajo que no debería haber tomado. La configuración del caché es uno de esos detalles técnicos que parece menor hasta que rompe producción en el peor momento posible.
La buena noticia es que tiene solución directa: claves de caché bien diseñadas, basadas en el contenido real de tus dependencias, no en nombres genéricos. Un cambio de una línea en tu configuración de CI puede salvarte semanas de debugging.
En Consultoría-Ti trabajamos con equipos de desarrollo que enfrentan exactamente este tipo de problemas: pipelines heredados, deuda técnica acumulada y sistemas que funcionan hasta que dejan de funcionar. Si quieres revisar la salud de tu infraestructura de CI/CD o modernizar tu proceso de deployment, conversemos.
Contáctanos aquí y evaluamos tu caso sin compromiso.
Fuentes y Referencias
Google for Developers — What caused this React app to crash? (YouTube Shorts)
✨ Contenido generado con ContentFlow — Consultoría-Ti