El día que rompí React Native

Hola a todos. Así que hoy quiero contarles una historia. Es la historia de un lluvioso día de noviembre del año pasado. Estaba en Seattle. Si alguna vez han estado en Seattle, asegúrense de visitar la Starbucks Reserve Roastery. Es un Starbucks especial donde hacen catas de café. Si te gusta el café, definitivamente querrás echarle un vistazo. Y yo estaba allí. Estaba revisando mi correo electrónico, revisando mis notificaciones de GitHub. Y sí, todo parecía genial. Pero luego la gente comenzó a enviarme mensajes de que por alguna razón sus compilaciones, sus compilaciones de React Native estaban rotas. Y bueno, estaba en Discord. Así que déjame ver qué está pasando realmente.

Y en React Native, ejecutarás Android para ejecutar la aplicación Android. Y la gente comenzó a informar sobre mensajes de error de la nada, de una manera realmente terrible. Imagina que tu compilación estaba funcionando hace un minuto, luego vuelves a compilar, no haces ningún cambio de código y tu compilación está rota. Esto es terrible desde el punto de vista de la experiencia del desarrollador. Y obviamente no debería suceder. Luego comenzamos a investigar, oye, ¿por qué estas compilaciones se están rompiendo realmente? Y nos dimos cuenta de que en el mensaje de error, se mencionaba una próxima versión de React Native, como 0.710.rc0. E incluso para los usuarios que estaban en versiones anteriores de React Native, como en 68 y 69 y así sucesivamente. En ese punto, nos dimos cuenta, sí, creo que tenemos un problema. Y personalmente tuve un gran problema porque se suponía que debía volar de regreso a Londres en un par de horas. Entonces, ¿cómo lo solucionamos?

Así que mi nombre es Nicola Corti. Trabajo como ingeniero de Android en el equipo de React Native en Meta. Y hoy estoy emocionado de contar la historia del día en que rompí React Native. Para entender completamente qué fue esto, les guiaré a través de lo que sucedió, qué fue el incidente real, por qué se rompió y cómo lo solucionamos realmente. Así que la advertencia aquí es, bueno, el incidente fue en Android, pero efectivamente rompimos la compilación para todos. Así que bueno, no muchas personas aquí usan React Native, pero confíen en mí, hay muchas lecciones aprendidas que se aplican a cualquier tecnología. Así que comencemos con lo que sucedió. Dentro de React Native y dentro del equipo de React Native, tenemos este grupo de personas llamado el equipo de lanzamiento.

Un cambio que es realmente relevante para este incidente es este RFC 508, que está fuera de la solución del paquete NPM para los artefactos de React Native. Prácticamente hablando, el paquete NPM de React Native se estaba volviendo demasiado grande. Ya no podíamos caber allí, y entraré en ello en un minuto. Pero tuvimos que encontrar una solución alternativa donde se pudieran enviar los artefactos de Android.

Cuando haces nativo, no solo distribuyes código, distribuyes binarios, y esos binarios se vuelven bastante grandes, y pueden llegar a cientos de megabytes. Así que decidimos mover los artefactos de Android del paquete NPM a Maven Central, que es donde generalmente se distribuyen las bibliotecas de Android. Así que este sitio web, que es bastante arcaico a juzgar por la cantidad de CSS que utilizan, es en realidad Maven Central. Así que no es más que básicamente un cubo S3 donde se almacenan las bibliotecas de Android. Y aquí es donde se almacena en realidad React Native y la gente que construye React Native lo obtiene de allí. Y si miras en la lista de versiones, verás que, bueno, solíamos publicar en Maven Central en el pasado. Si miras las versiones entre 0.11 y 0.20, que es como 2015, 2016, solíamos publicar allí. Pero luego en algún momento nos mudamos porque publicar en Maven Central era demasiado complicado, y entonces dijimos, está bien, hagamos un paquete monolítico y pongamos todo dentro del paquete de React Native. Bueno, entonces tuvimos que revertir esta decisión porque el paquete se estaba volviendo demasiado grande y publicamos 0.71.0.rc0, que ves justo debajo de allí, publicado en noviembre de 2022. Aquí.

Así que intentemos entender por qué ocurrió el incidente en primer lugar. Porque hasta ahora parece razonable. Cuando estábamos publicando en Maven Central en el pasado, volvíamos allí porque el paquete se estaba volviendo demasiado grande. Por qué las cosas se rompieron. Así que volvamos a este RFC y miremos más de cerca dentro del paquete npm. Como dije, la carpeta de Android era la mayor infractora aquí. Estamos hablando de 66 megabytes y en 0.71 estábamos añadiendo símbolos de debug y más cosas para mejorar la experiencia del desarrollador de Android, lo que hizo que el paquete de npm se hiciera más grande. Estaba llegando a más de 200 megabytes. Curiosamente, no puedes publicar paquetes de npm que superen los 220 megabytes o así porque npm te devolverá HTTP 4.1.3 contenido demasiado grande. Así que npm simplemente no era una opción. Así que tuvimos que eliminar esos binarios del paquete npm. El problema subyacente que desencadenó este incidente es lo que llamamos una dependencia plus, que es realmente similar a una dependencia de estrella en npm. Así que para Android, usamos Gradle para construir, y dentro del archivo Gradle tenemos un bloque donde describimos cuáles son nuestras dependencias, como qué bibliotecas queremos depender. Y una de estas es React Native. Esta cadena aquí se llama coordenadas maven gav. Sé que esto es muy específico para Android, pero también es bastante fácil de entender.

Entonces, gav significa grupo, que es la organización que publica una biblioteca, a para artefacto, que es el nombre de la biblioteca, y v para versión, que en este caso era más, lo que significa simplemente obtener la versión más alta que encuentres en cualquier repositorio y usarla.

Bueno, si miramos como esto es de la plantilla predeterminada. Entonces, cuando creas una nueva aplicación de React Native, tendrás como archivo Gradle y cosas como esos comentarios aquí, que creo que son un poco interesantes.

Entonces, por ejemplo, hay un comentario aquí justo arriba que dice no inspección Gradle versión dinámica. Esto es una supresión de una advertencia para la línea justo debajo. La línea de abajo contiene un más, que, bueno, en el espacio de Android es un antipatrón. Específicamente, hay esta página en la documentación de Gradle, que se llama manejo de versiones con cambios a lo largo del tiempo. Entonces, como versiones dinámicas. Y solo en la primera, como si tomo una captura de pantalla de esta página, tienen dos advertencias que te dicen que las versiones dinámicas no son geniales porque simplemente llevan a compilaciones irreproducibles. Básicamente estás a merced del mantenedor de la biblioteca. Si el mantenedor de la biblioteca mañana publica una nueva versión, simplemente la vas a obtener y tal vez tu compilación se rompe de la noche a la mañana. Entonces, no es genial, ni en NPM ni en ninguna otra plataforma que tenga un concepto similar.

Pero, ¿por qué funcionó? Para entender completamente, necesitamos ver este otro comentario a la derecha, que dice de node modules. Así que la dependencia plus funcionó hasta React Native 0.70 porque en realidad estábamos obteniendo la dependencia del paquete NPM. Si empiezas a mirar lo que hay dentro de node modules, React Native, añade la carpeta Android, veremos que básicamente allí tenemos una colección de artefactos. Tenemos como un sources.jar, un archivo pom y así sucesivamente. Esto es como cosas de Java que se utilizan para construir las aplicaciones Android. Estoy fingiendo un poco aquí, como que la lista es en realidad bastante más larga. Pero independientemente de eso, esta es la lista de artefactos que utiliza React Native para construir una aplicación Android, como el núcleo de React Native. Y si miras en Maven Central, ese es en realidad el mismo contenido. Así que simplemente movimos esa carpeta de node modules a otro repositorio. Así que ahora tal vez empieces a entender por qué ocurrió el problema. El problema ocurrió porque la dependencia plus significa obtener la más alta. Y mientras añadas solo una versión localmente dentro de tus node modules y una versión en Maven Central, que era menor, en este caso 0.20, las cosas funcionaban bien. Pero si publico algo en Maven Central o en cualquier otro repositorio que tenga una versión superior, esa versión prevalecería en todos los proyectos de este planeta. Así que la gente empezó a agarrar esa versión 0.71.0.rc0, lo cual no es genial.

Entonces, veamos cómo lo solucionamos realmente. ¿Cómo podemos arreglar las compilaciones para todos? Entonces, podrías pensar, está bien, entonces voy a mi proyecto y simplemente elimino el plus, ¿no? Especifico la versión que estoy usando, como 0.68, ¿no? Como si hubiera parcheado mi proyecto local. Bueno, eso es cierto, pero también un poco ingenuo porque en React Native, dependemos mucho de las dependencias externas, como en todos los proyectos node. Por ejemplo, una biblioteca muy popular para React Native es reanimated, una biblioteca de animación. Y también tienen un archivo griddle. Y dentro de su archivo griddle, también dependen de React Native. Y bueno, reanimated no quiere depender de una versión específica de React Native, solo quieren obtener la que el usuario está usando. Así que también tienen una dependencia plus en su archivo griddle. Eso significa que incluso si tu proyecto especifica 68, reanimated diría como, no, no, no 68, dame la más alta, quiero esa. Así que básicamente cada biblioteca estaba contribuyendo a romper el proyecto aún más.

¿Entonces cómo lo arreglamos? Básicamente estaba en el avión, esperando a despegar y abrí un problema en GitHub tratando de explicar cuál es el problema, y con una combinación de paquetes de parches y demás, cómo podemos mitigar efectivamente este problema en tu proyecto. Pero esto no era ideal, el hecho de que tuvieras que usar el paquete de parches o hacer ediciones locas en tu carpeta de módulos node no es ideal. No deberías estar haciendo eso. Así que, junto con el resto del equipo de lanzamiento y personas de la comunidad, lanzamos parches para todas las versiones de React Native hasta la 0.63. Y esto fue un gran esfuerzo, porque imagina que tienes una rama para un lanzamiento que hiciste hace tres años. No sabes si el CI está funcionando, no sabes cuál es el estado allí. Y quieres intentar lanzar una nueva versión desde allí. No es fácil. Bueno, lo logramos y realmente hicimos un esfuerzo extra, la gente trabajó toda la noche para arreglarlo de manera que solo tendrías una versión parcheada de React Native que contiene solo las correcciones necesarias para resolver el problema. Y bajamos hasta la 63 porque mantenemos un ojo en la cuota de mercado de las diversas versiones de React Native que ustedes descargan de NPM. Y 63 nos permitió cubrir el 99% de las descargas. Así que básicamente pudimos arreglarlo para todos. La solución definitiva, en realidad, fue contactar a Sonotype, que es la empresa que administra Maven Central y pedirles que eliminaran los artefactos. Esto llevó un poco más de tiempo, como dos días, porque inicialmente pensamos, está bien, nunca van a eliminar eso. Como Maven Central es un almacenamiento de datos inmutable, no se supone que debas eliminar bibliotecas. Pero en este caso, esta fue la única solución a este problema. Así que también nos ayudaron mucho en arreglar esto.

Ahora quiero compartir un par de lecciones aprendidas, cosas que yo y el resto del equipo de lanzamiento y el equipo de React Native nos llevamos de esta experiencia. Entonces, primero, muchas de las dependencias plus han sido eliminadas.

Como tenemos soluciones en marcha dentro de nuestra infraestructura tanto de Android como de iOS para prevenir problemas similares a este. Y también hemos considerado implementar lo que se llama una ventana de soporte de lanzamiento. Históricamente, se recomendaba estar en la última versión de React Native, lo cual sí funciona, pero no siempre es posible porque tu proyecto puede quedarse un poco atrás. Así que ahora somos más intencionales sobre qué versiones de React Native son realmente compatibles. Si miras en el grupo de trabajo de lanzamientos de React Native para React, verás que declaramos qué versiones de React Native admitimos. Y cuando decimos que admitimos, queremos decir que si encuentras un error en una de esas versiones, nos comprometemos a solucionarlo y lanzar un parche para ti. Esto cubre casi el 70, 75% de la cuota de mercado hasta ahora. Y esto permite cubrir un año entero de lanzamientos. Así que eso significa que aunque deberías actualizar tu versión de React Native y cualquier versión de dependencia que uses, tienes una ventana de un año para poder recibir siempre parches y parches de seguridad y demás.

Otra cosa que aprendimos es el tiempo de respuesta a incidentes. Personalmente creo que fuimos bastante lentos para responder aquí. El problema es que este fue un incidente de código abierto. No tenemos ninguna telemetría en React o React Native, así que no sabemos cómo van las cosas para ti. Como no sabemos si tus compilaciones están rotas. No sabemos qué dependencias usas y así sucesivamente. Así que el hecho de que alguien me dijera que su compilación está rota, no tengo la sensación de que esto significa que todas las compilaciones en el planeta están rotas. Así que quiero tocar un poco la cultura de incidentes en Meta para que entiendas cómo intentamos integrarnos dentro de la cultura de Meta y el espacio de código abierto. En Meta, utilizamos niveles SEV, que son como un estándar de mercado para expresar la gravedad de un incidente. Tenemos SEV4, que es el nivel más bajo, que es solo un aviso. Abrimos un incidente SEV4 siempre que hay algo que podría romperse, pero tal vez no. Por ejemplo, hicimos una gran migración de la estructura del monorepo de React Native, y siempre que mueves mucho código, las cosas pueden romperse. Por eso abrimos un SEV4 para ese caso. Tenemos SEV3, que significa problema significativo, la resolución es de moderada a alta prioridad, como algo se rompió, alguien debería mirarlo. SEV2, que es un problema mayor, la resolución es de muy alta prioridad, como un grupo significativo de personas se ve afectado. SEV1, alerta roja, todos a bordo, como generalmente uno de los productos de Meta está caído. Y luego SEV0, que significa crisis a nivel de empresa, como varios productos están caídos o las cosas están realmente mal. En este caso, esto fue un SEV2 porque todo el ecosistema de código abierto de React Native estaba roto, y tuvimos que despertar a la gente y encontrar una solución lo antes posible.

Otra cosa que nos llevamos a casa son las mejores prácticas de las bibliotecas. Como dije antes, las bibliotecas estaban contribuyendo a exacerbar el problema aquí porque cada una tiene su propia lógica de construcción, y pueden hacer, básicamente lo que pasa es que hay patrones en la comunidad que se copian. Tal vez empiezas una nueva biblioteca y copias otra biblioteca, y tal vez hay un anti-patrón allí que se pasa de una biblioteca a otra.

Es por eso que estamos invirtiendo en la creación de la biblioteca React Native, que es nuestro punto de entrada para crear nuevas bibliotecas. Hay un RFC abierto en el sitio web, que es la plantilla dorada para la creación de la biblioteca React Native. Así que queremos ofrecer mejores recomendaciones que estén aprobadas por Meta sobre cómo crear bibliotecas para React Native que sean resilientes a incidentes como este.

Y luego, bueno, un par de otras lecciones aprendidas que son bastante personales, pero se aplican a todos, creo. El día en que se invocó este script, fue un viernes. Así que incluso si estás trabajando en móviles, no hagas envíos los viernes. Y bueno, en este caso particular, en realidad, si miras la rama de lanzamiento de React Native 71, cada vez que ves un número de versión de revert bump, es un intento de publicar una versión que falló y se reinició. Sí, para ser justos, se suponía que este lanzamiento se iba a realizar el martes, y luego pasaron al jueves, y luego al viernes, y asumieron que todo funcionaría. Bueno, ese no fue el caso. Creo que en este escenario particular, en realidad, el hecho de que lanzáramos el viernes fue suerte. Tuvimos mucha suerte de que un problema como este surgiera durante el fin de semana para que tuviéramos tiempo durante el fin de semana para preparar lanzamientos de parches para todas las versiones de React Native en el mercado. Pero si esto hubiera ocurrido el lunes por la mañana, habríamos interrumpido el flujo de trabajo de los bancos, de las personas que están usando React Native en producción, y no pueden debido a problemas como este. Así que creo que ahora no hacemos lanzamientos los viernes por si acaso. Pero en este caso particular, tuvimos suerte.

Y la otra cosa es que, el Wi-Fi de los aviones es realmente terrible. Y asegúrate de no tener que lidiar con incidentes en un avión porque especialmente si necesitas transferir grandes binarios como artefactos para móviles, bueno, te va a llevar una eternidad. Así que si estás interesado en aprender más sobre este incidente, en realidad publicamos un análisis post-mortem en el blog de React Native. Puedes leerlo. Entra en más detalles sobre las tecnicidades de este problema. Y con esto, quiero agradecerte mucho por escuchar.

Mi única pregunta es, ¿cómo volviste a publicar en Maven o no lo hiciste? No. Entonces, sí, volvimos a publicar en Maven. Como que ahora las bibliotecas están en Maven Central. Y básicamente lo que hicimos, usamos nuevas coordenadas. Así que la biblioteca ya no se llama React Native, se llama React Android y sí. Sí, eso lo solucionará. Sí. Y también implementamos todas las cosas de alias. Entonces, si en tu archivo Gradle solicitas React Native, en realidad vamos a redirigir esa solicitud para resolver React Android. Sí, sí, porque creo que esa es una de las soluciones que es como, realmente no es posible ponerlo en el mismo lugar. Como que no creo que hubiera una solución rápida, es una de esas cosas que no tenías una solución rápida. Absolutamente.

Solo mira el profundo agujero del WiFi de Lufthansa. Estaba mirando a través de los como Sanatype usa Jira para interactuar con los clientes. Sí. Lo siento mucho por eso. No me sorprende. Básicamente, estaba mirando las solicitudes para eliminar paquetes y siempre estaban respondiendo como, no, nunca eliminamos nada. Solo publica una nueva versión de la biblioteca. Como si hubieras hecho una publicación falsa, puedes aumentar la versión. Sí, eso también es cierto en NPM y también en Crate para Rust, es lo mismo. Sí. Y yo estaba como, cada vez que publico, solo empeoraría esta situación. Como porque, ya sabes, hay esa versión que está ofendiendo porque su fuerza es mayor que las demás. Así que simplemente elimínalo. Y ellos fueron geniales en hacer eso. Creo que lo miraron y estaban como, ¿sabes qué? Nunca pensé que encontraría una razón por la que necesitaba eliminar una versión. Sí, como que encontré una. Absolutamente. Estaban como, su respuesta fue como, oh, eso es realmente interesante.

Lo siento mucho. Pero sí, fueron realmente útiles en esto. Y sí, una de las lecciones que obtuvimos de esto es también no intentar reutilizar cosas que usaste en el pasado. Básicamente, quiero decir, en este caso, deberíamos haber hecho más arqueología de Git para entender completamente por qué se usaba Maven Central en ese momento. ¿Por qué ya no se usa? Como que pensamos, OK, está ahí, simplemente sigue reutilizándolo. Pero sí, volvió a surgir.

¿Cómo te sientes mentalmente ahora que ha pasado un tiempo desde que ocurrió eso? Bueno, está bien. El día que estaba como, oh, Dios mío, esto es realmente malo. Como, sabes, en la masterclass estoy como si estuviera en los negocios. Pero tuve suerte y estaba como, OK, intentemos solucionar lo máximo posible. Y como le pregunté a mi colega, estaban en ese momento en Andover, lo cual sí, quiero decir, pudimos solucionarlo. Pero durante el fin de semana, nos quedamos despiertos e hicimos todos los parches. Y realmente como un problema allí es como para cuando estaba diciendo como para hacer un parche de React Native 0.63, necesitas Xcode 13, y luego CircleCI es como, no, eliminé Xcode 13. Este es como software obsoleto. ¿Por qué lo necesitas? Y yo estoy como, necesito publicar una biblioteca de hace tres años. Y necesito Xcode 13 porque esto se construye solo con Xcode 13 y así sucesivamente. Así que creo que otra lección aprendida aquí, solo más técnica y en el lado de Android y Android e iOS, intenta tener imágenes de docker de tu entorno de compilación, porque si tú compilas allí en el CI, básicamente tan pronto como cambien la versión de Java o la versión de Node o cualquier versión de cualquier herramienta en ese entorno, ya no puedes compilar. Para Android, tenemos imágenes de docker por lo que puedo bajar a, no sé, versiones antiguas de React Native y decir como, OK, reconstruye eso.

Todos aparecieron. Todos aparecieron ahora. OK. OK. OK. Eso es grande. Lo siento por eso. Entonces, ¿tienes una prueba manual testing? Oh, ¿tienes un proceso de prueba manual testing antes de lanzar nuevas versiones? Sí, lo hacemos. Tenemos una serie de pruebas de CI, principalmente pruebas unitarias. Confiamos mucho en las pruebas internas que ejecutamos en la infraestructura de materia. Entonces, por ejemplo, cada vez que envías una solicitud de extracción contra React Native, la importamos internamente y ejecutamos Oculus contra ella. Ejecutamos Facebook contra ella.

Entonces, si rompiste algo gravemente, lo descubriremos. Pero cuando hacemos un nuevo lanzamiento de React Native, probamos que eres capaz de crear un proyecto, que la nueva aplicación se inicia y así sucesivamente, porque la forma en que se utiliza React Native en código abierto e internamente en Meta es ligeramente diferente. Meta consume React Native desde la fuente, desde la principal. Entonces tus cambios van directamente a la aplicación de Facebook que sale la próxima semana. Mientras que para el código abierto, mientras se construye React Native lleva tiempo. Tienes más cuidado. Sí, quiero decir, obviamente, queremos asegurarnos de que con una línea de código, eres capaz de crear una nueva aplicación e iniciarla de inmediato sin depender de los cachés de compilación o algo así. Entonces, sí, simplemente intentamos hacerlo lo más óptimo posible.

Una pregunta más, ya que la cosa no aparecía, que es, ¿alguna vez has recibido un SEV cero? Y si es así, ¿cómo lo manejaste, cómo lo manejó alguien? ¿Alguien lloró? Así que nunca había recibido un SEV cero. Gracias. Afortunadamente. Pero si recuerdas, creo que en octubre de 2022, creo. Oh, los servidores estaban caídos o algo así. Sí, como que todo estaba caído. Como creo que Meta se cortó de internet y eso fue un SEV cero. Varias personas estaban despiertas y totalmente manos a la obra en eso. Me alegro de trabajar en móviles. Como siempre veo el Android. Así que los incidentes son bastante locos. Como si eso empieza a fallar, bueno, está bien, puedo hacer un nuevo lanzamiento y ponerlo en la tienda. Pero pasarán horas antes de que esté fuera, ¿sabes? Así que me alegro de no ser ingeniero de producción. No soy un SRE. Estoy de guardia a veces por cosas como el soporte de código abierto y cosas que necesitan atención inmediata o escenarios como este. Pero la gravedad de los problemas de código abierto que podemos tener nunca es tan alta como los servicios que están en producción.

OK, así que solo una más, porque siento que ganaste mucha tracción. Básicamente preguntaba si alguien se enfadó contigo. ¿Cuál fue la reacción de tu líder y compañeros de equipo? Espero que muchas otras empresas de tecnología allá afuera, no tengamos una cultura de culpabilidad alrededor de los incidentes. Los incidentes pueden suceder. En realidad no estaba en el equipo de lanzamiento. Como no envié ese script, no era responsable. Pero en realidad, escribí la infraestructura que causó esto. Así que me sentí responsable, obviamente. La reacción fue como, sí, rompimos cosas. Arreglémoslo lo más pronto posible, porque nos importa mucho nuestra community de código abierto. Así que intentemos darles la mejor solución. Como cuando añadimos esos fragmentos y parches por ahí, era como, seguro. ¿Pero podemos hacerlo mejor? ¿Podemos hacer versiones de parche para las versiones de React Native hasta el 99 por ciento de los usuarios? Sí, podemos.