¿Qué hay en un bug de Node.js – Un estudio de caso

Sí, hola a todos, y gracias por unirse a esta charla. Así que, voy a hablar sobre un error de Node.js.

Una rápida introducción sobre mí. Así que, hola, soy Anna. Actualmente soy ingeniera de personal en MongoDB trabajando en las suites de herramientas para desarrolladores. Si alguna vez has usado MongoDB, estoy segura de que muchos de ustedes lo han hecho en algún momento. Estoy trabajando en un par de cosas más. También soy excontribuyente del núcleo de Node.js, he estado bastante activa en el pasado, y soy miembro del comité de dirección técnica en ese lado. Estoy muy, muy apasionada por la codificación de caracteres. He dado charlas sobre ese tema antes. Sé que puede parecer un poco aburrido a veces, o no como si, ya sabes, no es como tecnología de vanguardia, pero sigue siendo algo que creo que siempre genera conversaciones interesantes. Así que, así es como puedes contactarme. También subí las diapositivas en este enlace aquí, si quieres buscarlas en algún momento más tarde.

Así que, sí, antes de que realmente hablemos sobre el error de Node.js al que me refería, hagamos un rápido repaso sobre qué son realmente las codificaciones de caracteres específicamente. Así que, como en una aplicación típica, tienes tu código que ejecutas. Ese es un programa separado. Y de alguna manera se comunica con un sistema operativo o núcleo, que, ya sabes, se encarga de comunicarse con el mundo exterior para tu aplicación. Y la forma en que hemos construido el software resulta ser que este sistema operativo o núcleo principalmente, ya sabes, recibe y envía información en forma de secuencias de bytes. Pero tu aplicación típicamente trabaja con la lógica de secuencias de caracteres, que generalmente se llaman cadenas. Y así, para poder trabajar con cadenas dentro de tu aplicación, necesitas tener algún tipo de conversión en la que todos estén de acuerdo para comunicarse con el mundo exterior. Y esas conversiones se llaman codificaciones de caracteres.

Y así, como algunas de las primeras codificaciones de caracteres estandarizadas, todos conocen ASCII, estoy segura de que era una forma de codificar la mayoría de los caracteres del idioma inglés, sigue siéndolo. Y pero eso significa que hay caracteres que no puedes representar. Y luego, con el tiempo, obviamente, ya sabes, la gente reconoce la necesidad de poder representar otros caracteres. Así que, una de las más populares que también es especial por razones históricas es esta ISA88591, que al menos cubre muchos caracteres de Europa Central. Pero, obviamente, eso, ya sabes, también alcanza sus límites. Quieres poder representar caracteres chinos, vas a tener que idear algo nuevo donde no puedes representar cada carácter con un solo byte. Y así, Unicode apareció y esto comenzó a ser realmente popular a finales de los 90, principios de los 2000. Y eso esencialmente convirtió este proceso en un proceso de dos pasos donde a cada carácter que deseas poder representar, le asignas un número. Y luego a ese número, le asignas una secuencia de bytes.

Y así, dos de los más populares y los que son particularmente relevantes para esta conversación hoy son UTF8, que es como, ya sabes, compatible hacia atrás con ASCII en lo que respecta a las secuencias de bytes. Simplemente comienza a hacer algo especial para las secuencias de bytes que están fuera del rango ASCII. Y UTF16, que es una forma que no es compatible con ASCII en absoluto. Pero si miras esto con más detalle, puedes ver que todavía hay algunas representaciones compartidas de caracteres y algunas, ya sabes, una historia compartida cuando se trata de cómo se representan exactamente las cadenas.

Y así, creo que la mayoría de ustedes como desarrolladores de JavaScript habrán escuchado la, ya saben, afirmación de que JavaScript usa UTF16, ¿verdad? Así es como funcionan las cadenas en JavaScript. Y eso es como, eso no es del todo incorrecto, pero tampoco es cierto. Y así, si miramos el código fuente del motor de JavaScript que usa Node.js y que usa Google Chrome, y muchas aplicaciones de JavaScript utilizan hoy en día, podemos mirar el código fuente de los podemos buscar todas las cadenas que esta implementación define, y podemos ver que en realidad hay muchas representaciones muy diferentes para las cadenas. Y hay dos que son particularmente dignas de destacar, que te mostraré en un segundo.

Así que, si quieres inspeccionar, por ejemplo, cómo V8 representa internamente esta cadena aquí que estoy construyendo, es como una concatenación y luego una repetición y un substring de eso. En realidad hay una forma de hacer eso. Necesitas exponer los internos de V8 para eso. Así que, esto no es algo que podrías hacer en una aplicación de producción. Pero hay este ayudante de impresión de depuración que V8 proporciona y necesitas pasar una bandera especial para habilitarlo. Y en realidad puedes mirar, como, ya sabes, hey, ¿qué contiene esta cadena? Y así, por ejemplo, para esta, va a decir que es un tipo de cadena const, lo que significa que está concatenada. En realidad se representa internamente como la concatenación de dos cadenas, no como una sola secuencia en memoria. Y así, si descomponemos esto, podemos ver que, como, sí, es una concatenación de una cadena de un byte o una cadena de un byte es lo que V8 llama. Y una cadena deslizante, que se representa por cadenas de dos bytes. Y entraremos un poco en por qué eso es un mal nombre. Pero el punto que estoy tratando de hacer aquí es que los motores de JavaScript van a ser inteligentes sobre cómo representan internamente las cadenas.

Así que, de todos modos, veamos específicamente qué sucedió en este error de Node.js del que se supone que esta charla debe tratar. Así que, esto sucedió en agosto de 2024. Puedes ver, ir al rastreador de problemas de Node.js. Todos estos son del repositorio de GitHub de Node.js core. Y puedes ver que hay un montón de informes de errores sobre algo raro que está sucediendo con UTF-8 y codificaciones de caracteres. Y si miras estos informes con un poco más de detalle, hay algo interesante en ellos que todos comparten. Y esto es, como, estos fragmentos específicos, como, es inestable. No es determinista. Falla después de que ya ha corrido por un byte. Ocurre esporádicamente.

Así que, como, eso es muy interesante cuando miras un error de la manera en que sucede. Porque, como, la mayoría de los errores son, o bien, como, ya sabes, algo está roto o no lo está. Pero aquí parece que hay algo más sucediendo. Y eso en realidad lleva a un agujero de conejo muy interesante sobre, ya sabes, cómo funcionan los motores de JavaScript hoy en día y en qué están trabajando las personas del núcleo de Node.js estos días. Pero, como, como con cualquier error, comencemos tratando de obtener un mínimo de reproducción. Así que, como, estoy escribiendo este script de prueba. Es muy simple. Toma la cadena. La convierte de una cadena a un buffer usando UTF-8, la convierte de nuevo usando UTF-8. Así que, en teoría, deberíamos obtener la misma cadena de vuelta. Sin embargo, aparentemente, eso no sucede. Y si medimos, como, cuánto tiempo tarda en suceder, podemos ver que en realidad es no determinista. Es, como, alrededor de 10,000 iteraciones de este bucle. Pero no exactamente. Y así, sigue siendo lo suficientemente bueno como para reproducirlo y ver si esto está fallando o no, ¿verdad?

Así que, podemos hacer lo siguiente que típicamente haces cuando tienes un error que realmente no sabes de dónde proviene. Haces git bisect. Y git bisect apunta a esta solicitud de extracción particular en el repositorio central de Node.js. Así que, algún cambio que tiene que ver con buffers, con las cadenas de un byte, como lo llaman aquí en esta PR y en la API de V8. Y, como, sí. Así que, esto tiene algo que ver con ello, seguro.

Y veremos un poco más, como, la diferencia exacta aquí. Y así, hay esta adición de llamadas a métodos rápidos donde esto está en la parte del archivo donde los métodos de C++ se exponen a JavaScript como funciones de JavaScript. Y podemos ver que estos diferentes, tres métodos diferentes, uno para ASCII, uno para Latin1, que es otro nombre para ISO 88591, y para UTF-8, comparten la misma implementación de este método rápido, que es solo escritura rápida de cadenas. Pero diferentes de la versión lenta. Y eso ya es interesante, porque, como, ya sabes, supongamos que estas funciones hacen lo que su nombre indica, ¿verdad? Y así, como, convierten las cadenas de JavaScript en secuencias de bytes. Las escriben en un buffer. Por eso se llama escribir cadena. Y el hecho de que todas compartan la misma implementación en el caso rápido, eso ya es interesante, ¿verdad? Así que, si miramos ese método particular un poco más, esta escritura rápida de cadenas, sabemos de dónde proviene este error. Y tenemos todas las piezas del rompecabezas ahora en este punto.

Entonces, ¿qué sucedió específicamente aquí y por qué? Primero que nada, este PR proviene de el hecho de que los contribuyentes del núcleo de Node.js se preocupan por el rendimiento. Parte de eso es el hecho de que en los últimos años, como todos saben, ha habido entornos de ejecución de JavaScript alternativos del lado del servidor, o, ya saben, fuera de los entornos de ejecución del navegador que afirman ser más rápidos. Y estoy seguro de que en algunos casos realmente lo son. Además, hay, obviamente, alguna, como, ventaja real de tener software rápido. Significa que tus aplicaciones pasan menos tiempo haciendo cosas que pueden traducirse en ahorros reales si ejecutas tu aplicación en la nube y de repente necesitas menos recursos. Eso es siempre muy, muy bueno para tu billetera.

Así que, hacer este tipo de trabajo también es una buena manera de contribuir a Node.js de alguna manera. Porque sé que mucha gente quiere hacerlo. Y, ya saben, no siempre tienes, como, si llegas con la idea de querer contribuir, no siempre tienes la idea de, como, en qué te gustaría contribuir y cuáles son tus áreas en las que te gustaría trabajar. Pero, como, hacer las cosas más rápidas es algo que siempre puedes hacer, ya saben, para la mayoría de las piezas de software, al menos.

Así que, estas llamadas a métodos rápidos que vimos antes, hay algo que se llama incrustar API rápida. Y necesitamos entender qué es esto específicamente para entender por qué está ocurriendo este error y por qué está ocurriendo de esta manera específica. Así que, como, en el pasado, una de las maneras más fáciles de optimizar el trabajo del núcleo de Node.js ha sido eliminar preguntas de límite entre C++ y JavaScript. Así que, como, tu aplicación de JavaScript llama a C++. O viceversa, si hay algún evento ocurriendo en el bucle de eventos, que ocurre en C y C++, y necesita informar a tu aplicación que algo sucedió, necesita llamar de vuelta a JavaScript. Y estas siempre han sido, como, partes bastante costosas de tus aplicaciones. Porque hay mucho, como, trabajo de configuración que los motores de JavaScript hacen antes y después de que entras en una de estas áreas específicas, ya saben, si quieres llamarlo así. Y así, para resolver este problema, tuvimos que introducir algo llamado la API rápida. Hasta donde sé, todavía es técnicamente experimental. Pero, como, se ha estado demostrando como un verdadero, ya saben, tesoro de optimizaciones para entornos de ejecución de JavaScript. Y así, eso elimina gran parte de este overhead de los cruces de límites entre C++ y JavaScript. Solo funciona en una dirección. Así que, solo puedes llamar a C++ desde el código de JavaScript, no al revés. Pero tiene algunas precondiciones. Como, no puedes simplemente hacer que todo use la API rápida y terminar con eso y, ya saben, nunca preocuparte por ello de nuevo. Solo se aplica en algunas situaciones muy específicas que tu motor de JavaScript puede detectar en tiempo de ejecución. Así que, como, tus datos necesitan estar organizados de una manera que permita esta optimización. La función de la API rápida no puede hacer nada que desencadene la recolección de basura. Así que, como, no crear nuevos objetos. No crear nuevas cadenas, ya saben.

Y no puede llamar de vuelta a JavaScript. Porque eso podría, obviamente, también desencadenar la recolección de basura. Porque no sabes lo que hacen tus funciones de JavaScript. Y así, la idea es, escribes dos implementaciones de una función en C++. Una que es lenta y una que es rápida. Y las llamadas rápidas solo se utilizan después de que V8 detecta que tu código se ha ejecutado muchas veces. Y así, necesita optimizarlo. Quiere optimizarlo. Y recompila tu función de JavaScript que se llamó muchas veces para poder hacer uso de la API rápida. Y una cosa particular que vale la pena mencionar sobre esto es que V8, nuevamente, es un software muy inteligente. Puede hacer esto de manera asíncrona.

Así que, como, puede tomar tu código de JavaScript, notar que se ha llamado muchas veces, notar que debería ser optimizado, pero luego hacer esa optimización en otro hilo en tu aplicación. Así que, como, no detiene la ejecución de tu código. Simplemente, como, dice, hey, esta función necesita ser optimizada, recompílala, pásala a otro hilo. Y una vez que haya terminado, comienza a usar esa nueva implementación de tu función. Súper inteligente, realmente, si piensas en ello. Y así, volvemos al ejemplo de antes, y miramos esto, y todo se junta, ¿verdad?

Así que, como, la razón por la que esto sucede después de un número inestable de iteraciones y solo después de un montón de ellas es que esta función, este buffer.from en este caso, necesita ser llamada muchas veces para hacer que el motor se dé cuenta, hey, vale la pena gastar tiempo en optimizar esto. Vale la pena gastar energía en ello. Porque sucede en un hilo separado, solo sucede después de un número desconocido, pero indeterminista de iteraciones. Así que, definitivamente, de ahí proviene este error. Y así, te dije que hay, como, dos de estas representaciones de cadenas que valen la pena prestar especial atención, ¿verdad? Y así, una de ellas, una cadena de bytes, ese es el nombre de V8 para ISA88591, y la cadena de dos bytes, ese es el nombre de V8 para UTF-16. Y esas son solo, como, las, así que, seis representa secuencial. Así que, esas son las representaciones secuenciales donde una cadena es realmente solo, como, una secuencia de bytes en memoria sin ninguna subcadena especial o corte o, ya saben, concatenación o algo así.

Así que, si miramos nuevamente esta diapositiva de antes, donde miramos la implementación del método de escritura rápida de cadenas, podemos ver, está bien, así que, este método de escritura rápida de cadenas tiene el requisito, el segundo argumento que recibe, es una cadena de un byte. Y si recuerdas la diapositiva anterior, eso significa que es una cadena ISA88591. Y así, copia esto en el destino desde la fuente, desde esta cadena ISA88591, y este método no hace ninguna otra verificación. Así que, si recuerdas, estábamos usando esta implementación para UTF-8 también. Y así, eso no es lo que debería estar haciendo. Simplemente copia literalmente secuencias de bytes de algo que es una cosa a algo que se supone que debe ser otra cosa. Esa es también la razón por la que este error, por ejemplo, no se reprodujo con todos los caracteres.

Como, si miras esta diapositiva de nuevo, ves que solo ocurrió con la E acentuada, donde, por ejemplo, los otros caracteres fueron, ya sabes, preservados, porque esos son los que realmente difieren entre UTF-8 e ISA88591. Esto también, por ejemplo, no ocurriría si la cadena contenía caracteres chinos o emoji, porque entonces no tendría este requisito previo cumplido de ser una cadena rápida de un byte, como algo que es representable usando ISA88591. Y así, sí, de ahí proviene esto.

Y obviamente tendrías toda la razón al pensar, como, algo debería haber detectado esto, ¿verdad? Es muy desafortunado. Así que, como, si miras el informe de cobertura en la solicitud de extracción que mencioné, que, por cierto, no quiero culpar a la persona que abrió esa solicitud de extracción. Esto es algo que es muy fácil de pasar por alto. Sí, el PR de cobertura, los datos de cobertura para ese PR, indican que las nuevas rutas de código fueron tomadas durante las pruebas. Simplemente, como, no sucedió que se tomaran en la prueba que cubriría estas preguntas específicas de codificación. Así que, la cobertura realmente no te da la respuesta aquí. También hubo benchmarks que en realidad habrían detectado este problema, pero, ya sabes, estás escribiendo benchmarks, esos no son pruebas, y así que no había nada allí que verificara los resultados de estas operaciones, lo que, ya sabes, si estás escribiendo benchmarks, eso es absolutamente comprensible.

Y Node.js también tiene esta cosa genial donde en realidad hace algo donde ejecuta un montón de paquetes NPM populares contra una versión de desarrollo de Node.js. Así que, de nuevo, esto es algo que sucede antes de que cualquier lanzamiento salga en el repositorio principal de Node.js. De nuevo, hubo algunas fallas que fueron detectadas. Todas fueron revisadas y ninguna resultó ser relacionada con este error en particular, muy probablemente porque este error en particular solo se desencadena si, ya sabes, un fragmento particular de código se ejecuta mucho, y eso simplemente no sucedió en ninguna de las pruebas en estos paquetes NPM. Es desafortunado, así que esto en realidad llegó a un lanzamiento. Hay un montón de cosas que podemos aprender de esto, creo, y así algunas cosas muy directas de ingeniería de software, ya sabes, lo has oído antes, nombrar es un problema difícil. Si una cadena de un byte se hubiera llamado algo como latin1str, o iside8591str, esto podría no haber sucedido porque la suposición de que solo se desencadenaría para cadenas ASCII ni siquiera habría sido un tema. Además, la cobertura es muy limitada, y lo que te dice, necesitas probar realmente el cambio que estás haciendo y no solo asegurarte de que tus nuevas y viejas rutas de código estén cubiertas.