Una Fuga en el Shell – Cómo la Refactorización del Autocomplete Nos Rompió y Cómo lo Arreglamos

Muy bien. Bueno, me alegra que tantas personas estén aquí para escucharme hablar sobre JavaScript. Siempre me encanta eso. Pero sí, de todos modos, este soy yo. Puedes encontrarme en Blue Sky si quieres contactarme en algún momento después de la conferencia. Tendré las diapositivas en línea si quieres consultar algo después. Y de lo contrario, sí, este soy yo.

Antes de que entremos en los problemas reales con los que nos encontramos, déjame darte un pequeño resumen de lo que realmente queríamos hacer. Puede que sepas si alguna vez has usado MongoDB que tenemos un CLI de base de datos que puedes usar para interactuar con tu base de datos. Esto no es como una charla de producto de MongoDB, pero quiero darte el contexto de lo que estoy hablando. De todos modos, sí, nuestro CLI de base de datos se llama Mongosh, cualquiera de los dos está bien. Así que puedes escribir JavaScript en este CLI de base de datos para interactuar con tu base de datos. Y en algún momento pensamos, bueno, está bien, tenemos un autocompletado rudimentario en esto, pero ¿no sería genial si el autocompletado en nuestro CLI pudiera ser mucho más consciente del contexto y mucho más útil para nuestros usuarios?

Por ejemplo, si tienes este documento almacenado en tu base de datos donde tienes un pedido y un cliente y potencialmente muchos otros campos que no serían relevantes aquí, y luego podrías autocompletar en estos campos después de hacer una llamada como esta. Eso debería ser posible en teoría, ¿verdad? Y entonces estábamos como, está bien, ya tenemos autocompletado, pero podríamos hacer uno mucho, mucho mejor. Así que comenzamos a tener un plan, y la primera idea fue, bueno, está bien, hay un buen autocompletador para JavaScript que millones de personas usan todos los días, y todos en esta sala lo han usado miles de veces, que es como el motor de autocompletado de TypeScript, ¿verdad?

Y entonces pensamos, bueno, podríamos simplemente aplicar esto a la base de datos, como a la entrada de nuestro CLI, ¿verdad? No debería ser muy difícil. Así que nuestro plan que ideamos fue como, bueno, vamos a analizar el esquema de la base de datos del usuario para tener una idea de cómo lucen sus documentos. Tenemos una idea bastante buena de cómo luce nuestra API, solo necesitamos poner eso en TypeScript en un formato que sea comprensible para, sí, para el autocompletador de TypeScript que se almacena y guarda como archivos DTS regulares, así que nada demasiado sofisticado, o al menos, como, quiero decir, estos no son archivos reales, están completamente en memoria, pero el mismo concepto.

Y luego tomamos estos archivos DTS, tomamos la entrada del usuario, y los pasamos al autocompletador de TypeScript, ¿verdad? Y eso suena lo suficientemente fácil, con suerte. Y sí, si pruebo esto ahora mismo con la versión actual de nuestro CLI, en realidad autocompleta los nombres de los campos cuando hago tap tap dentro del CLI, así que encantador. Y todo el crédito donde se debe, la mayor parte del trabajo de implementación para esto fue realmente hecho por mi compañero de trabajo que está aquí sentado viéndome hablar sobre su trabajo. Pero sí, de todos modos, esto es como, obviamente hay más en ello, porque de lo contrario habría terminado después de dos minutos de hablar, ¿verdad?

Y entonces, bueno, sí, funciona. ¿O no? Bueno, implementamos esto, y lo probamos, y funcionó bien, y lo pusimos detrás de una bandera de característica, y le dijimos a la gente, oye, si trabajas en MongoDB, si quieres probar esto realmente, por favor hazlo, este es un nuevo autocompletador. Y así, antes de publicar esto, solo, ya sabes, haciéndotelo saber. De todos modos, luego, después de un par de meses de probarlo internamente, creo que decidimos cambiar la bandera de característica, y eso no salió bien. Así que lo que estás viendo es, bueno, nuestras pruebas comenzaron a fallar.

Entonces, lo que estás viendo es que nuestras pruebas comenzaron a fallar. Las pruebas comenzaron a fallar con errores de falta de memoria mientras probaban la parte de autocompletado de todo esto. Así que eso obviamente no es genial. Bueno, ¿cómo empiezas a depurar algo así? Esto resultó ser bastante complicado en nuestro caso, ¿verdad? Porque, si quieres depurar algo, comienzas con un ejemplo mínimo que reproduzca el error, ¿verdad? Ese es siempre el primer paso. Pero cada prueba pasaba por sí sola. Así que esto obviamente era algo que estaba sucediendo porque estábamos ejecutando pruebas en combinación. Lo cual, sí, esto hace que sea más complicado.

De todos modos, todavía podemos intentar minimizar cuánto tiempo lleva llegar a esto. Y así, por ejemplo, con Mocha, que es un ejecutor de pruebas que todavía usamos felizmente, nunca realmente he sentido la necesidad personalmente de cambiar a una de las nuevas cosas geniales y elegantes. De todos modos, todas me parecen iguales. Pero de todos modos, con Mocha puedes pasar banderas de Node.js a la instancia real de Node.js. Y así, lo primero que puedes intentar es simplemente reducir el tamaño del heap. Y así, el tamaño del heap, es como cuánta memoria puede asignar tu código JavaScript. Y si reduces eso, obtendrás errores más rápido. Y eso obviamente ayuda un poco con la reproducción, pero no es toda la historia, ¿verdad?

Así que vamos a tener un fallo. Y de alguna manera necesitamos ver qué hay realmente en la memoria aquí, ¿verdad? Y así, personas inteligentes, creo que en realidad esta primera bandera que mencioné aquí, esta instantánea del heap cerca del límite del heap, fue implementada originalmente por Joey, quien también es un orador hoy, creo en la otra sala justo después de mí. Pero hay una bandera más nueva que es solo instantánea del heap en OOM. Y básicamente le dice a Node.js, bueno, si te encuentras con errores de falta de memoria antes de fallar, simplemente escribe una instantánea de tu memoria en el disco. Así que puedes hacer eso. Obtienes un archivo que se escribe en el disco llamado instantánea del heap punto algo, algo, algo. Y puedes abrir eso en Google Chrome. De hecho, aprendí mientras preparaba esta charla que también puedes abrirlo dentro de VS Code directamente, lo cual es, no sé, interesante, pero no tiene toda la misma funcionalidad para investigar realmente los problemas. Pero de todos modos, estamos viendo que hay un montón de diferentes objetos en la memoria. Estamos viendo que el autocompletador está por ahí en el número cinco.

Pero también puedes ver que hay grupos de objetos que ya puedes identificar. Hay muchos objetos que juntos ocupan 640,000 kilobytes en memoria. Y eso probablemente significa que simplemente se están manteniendo vivos entre sí y esta herramienta realmente no puede decir dónde está el culpable, ¿verdad? Así que el autocompletador tiene algo que ver con esto. Pero lo que es potencialmente más interesante es este primero que está allá arriba en la lista, que es system slash context. Y podrías preguntarte, bueno, ¿qué es eso? De todos modos, si miramos uno de ellos, podemos ver que hay esta cadena de cosas que retienen este objeto en particular. Lo que puedes hacer en esta vista es hacer clic en un objeto y ver estos son los otros objetos que mantienen vivo a este. Y puedes ir hasta cualquier raíz que haya, como el objeto global, por ejemplo. Eso podría ser uno o, ya sabes, como un socket de red. Esas serían raíces de recolección de basura. Pero sí, hay estos contextos del sistema, y hay cosas como nuestros autocompletadores que están siendo mantenidos vivos por ellos. Entonces, ¿qué es el contexto del sistema? Eso fue como... Esto no es algo que aparece en tu código, ¿verdad? Esto es algo que necesitas aprender. ¿Qué es esto, en realidad? Y así, para hacer eso, tal vez retrocedamos un segundo. Y así, solo piensa en casos muy, muy simples de retención de memoria. Creo que este es tan simple como se puede, ¿verdad? Tenemos el objeto global y tenemos una propiedad A, que es un objeto con una propiedad B, con una propiedad C, y luego un gran trozo de memoria que está garantizado que aparecerá como luces de Navidad en una instantánea del heap. Y si miramos la instantánea del heap para esto, resulta ser cierto. Es una de las primeras cosas que se mencionan. Hay algo que retiene 10,000 kilobytes de memoria. Eso es prácticamente lo que esperaríamos. Y podemos ver, si miramos este pedazo de datos de array buffer, sí, eso está siendo almacenado en algo llamado backing store, que es como un concepto interno de V8 que es propiedad de un buffer, que es la propiedad buffer de un UN8 array, que luego se llama realmente gran blob, que es retenido por C, B, A en global. Así que es más o menos lo que esperarías. Así es como lees estas instantáneas del heap cuando las inspeccionas en DevTools. Así que eso es prácticamente lo que esperaríamos. Y global es obviamente una raíz. Si expandieras esto, solo habría global y realmente nada debajo de él. Pero tal vez vayamos por un ejemplo más complicado, ¿verdad? Así que nuevamente asignamos una gran pieza de memoria que está principalmente allí para aparecer como una gran pieza de memoria cuando la inspeccionamos. Y programamos un intervalo que registra hecho cada segundo, pero también programamos un timeout que hace algo con este blob. Este timeout se borra después de un milisegundo, y después de eso, está hecho, ¿verdad? Así que el callback pasado al segundo set timeout, esta función B, no debería mantenerse viva en memoria. Y no lo hace. Pero luego aún tomamos una instantánea después de que ese timeout se haya ejecutado.

Podemos ver que todavía hay algo que mantiene vivo este gran blob. Es el contexto en la función A, no en la función B. Así que el contexto, como podemos inferir, significa que estos son los ámbitos léxicos que tus cierres han capturado. Y debido a la forma en que funcionan los motores de JavaScript, cuando capturas variables, potencialmente capturas todo lo demás que está en el ámbito también. Y así, realmente no es obvio, porque ¿qué captura esta función A? Entonces es la variable console, ¿verdad? Es como algo del ámbito exterior, lo cual es suficiente para hacer que capture todo el ámbito, lo cual es suficiente para retener este gran blob indefinidamente, aunque al menos en teoría un motor podría decir que nunca será accedido de nuevo.

Y eso nos acerca un poco a entender por qué nos encontramos con estos problemas. Pero hay un poco más. Un aspecto divertido de JavaScript que también entró en juego. Entonces, ¿qué imprime esto? ¿Alguna idea? No es una pregunta trampa. Sí, 4. Gracias. ¿Qué imprime esto? ¿Alguna idea? Sí, 4. ¿Qué imprime esto? No, no 4. ¿Cómo te atreves a pensar eso? Así que en realidad hay dos tipos de eval en JavaScript. Está la palabra clave eval, donde si simplemente llamas a la palabra clave eval directamente, heredará el ámbito exterior de lo que estás ejecutando. Así que es como ejecutar una función, como un callback, pero si te refieres al global que es lo que obtienes cuando ejecutas eval eval, no obtienes el ámbito exterior.

Y así, esta cuarta línea aquí en realidad solo lanza una excepción porque no puede encontrar A en su ámbito porque no se ejecuta en ese ámbito. Y esto puede ser realmente complicado porque hay diferencias muy sutiles entre llamar eval, por ejemplo, y luego llamar, si estuvieras, entre paréntesis, un extremo y eval. Esos serían objetivos de llamada completamente diferentes según la especificación de JavaScript. Así que de todos modos, con ese conocimiento, podemos entender los errores y las correcciones que encontramos aquí. Y obviamente hubo algunas cosas innecesariamente tontas que aprendimos cuando, ya sabes, arreglamos esto. Y una es como, bueno, hay esta clase que tiene una documentación que dice que cierra todos los recursos abiertos mantenidos por esta instancia de REPL, y luego no cierra o no cerraba previamente uno de los recursos principales que mantenía, lo cual es como, sí, eso va a filtrar tu memoria. Pero luego sí, también es realmente difícil de detectar, y eso fue como las cosas de las que estaba hablando. Obviamente hay esta línea extra que también es parte del problema aquí, pero reemplazar eval con esta función eval sin contexto y eval sin contexto es realmente solo como eval puesto en un archivo separado para que no pueda capturar ninguna variable.

Eso es todo. Ese es el núcleo del error que corregimos aquí. Porque de lo contrario, esta llamada eval que tuvimos que hacer no podría, como, obviamente eval es malvado y lo sabemos y no deberíamos estar haciendo esto, pero en nuestro caso esto es justo lo que tenemos que hacer. Esto en realidad estaba capturando suficiente del ámbito exterior que estaba manteniendo objetos en memoria por mucho más tiempo del que deberían haber estado.

Y luego, como en cualquier buena historia, hay un error en el núcleo de Node.js que terminamos corrigiendo. Así que, como, aprendimos que el manejo de oyentes en el núcleo de Node.js REPL en realidad tenía un problema muy similar donde estaba llamando al proceso de prependListener, básicamente añadiendo un oyente de eventos, y estaba pasando un callback. Y ese callback no dependía de ninguna variable en el ámbito, pero aún así era suficiente para capturar todo el ámbito exterior, por lo que mantenía viva la instancia de REPL que lo creó aunque eso era completamente innecesario.

Y la solución es simplemente llevar esto al nivel superior para que no sea el cierre que captura la instancia real de REPL que lo añade más. Así que, sí, algo bastante fácil de pasar por alto, pero afortunadamente se nos permite hacer contribuciones de código abierto al núcleo de Node.js, y podemos simplemente corregir esto. Así que de todos modos, y llegando al cierre de esto, podrías preguntarte cómo realmente pruebas esto. Obviamente corregimos todos estos errores y luego nuestro CI estaba en verde, pero, ¿cómo te aseguras de que no retrocedes en esto, verdad?

Es como, obviamente, aún podrías, ya sabes, notar si las cosas van realmente mal y introduces fugas de memoria similares a las que vimos anteriormente, pero si algo va un poco mal, no lo notarás de inmediato. Y parte del núcleo del problema es que la recolección de basura en JavaScript es inobservable, ¿verdad? O al menos esto solía ser cierto durante mucho, mucho tiempo. Ya no lo es.

Así que algunas de las cosas más nuevas, esto tiene un par de años en este punto, pero hay algo llamado Finalization Registry en JavaScript ahora, y usarlo es increíblemente difícil, y yo diría, o no usarlo, usarlo correctamente es increíblemente difícil. Usarlo es bastante fácil, en realidad. Pero sí, esto es complicado de hacer bien, pero puedes observar la finalización de objetos a través de esta API.

Como, puedes obtener un callback que se llama cuando un objeto es eliminado del heap de JavaScript. Así que, perfecto. Hay algunas APIs específicas de Node.js que puedes usar. Está V8.QueryObjects, que es bastante genial.

Está V8.QueryObjects, lo cual es bastante genial. Te animaría a probarlo, en una de tus aplicaciones en algún momento, donde puedes pasar un constructor a esta función, y te dará todos los objetos en memoria que son creados a partir de este constructor. Y así, esta es como una manera fácil de saber si hay algo que todavía está en memoria que no debería estar. No fue realmente útil para nuestro caso de uso aquí, porque entonces habríamos tenido que mantener el constructor también, ¿verdad? Y eso fue un poco complicado para nosotros hacerlo correctamente.

Y luego está la función V8.GetHeapSnapshot, que es como, te da un HeapSnapshot completo en el formato que mostré aquí, y abierto en Chrome DevTools. Y esto es lo que usamos. Terminamos usando finalization registry y V8.GetHeapSnapshot, y luego analizamos el HeapSnapshot programáticamente como parte de nuestra prueba, lo cual fue como, es un poco de código extra, pero en realidad no es un formato tan complicado. Así que eso es bastante factible.

Pero para esos en especial, ten en cuenta, son solo herramientas de diagnóstico. No las uses en producción. No las uses en ningún lugar donde el rendimiento sea súper, súper sensible, porque como, especialmente V8.GetHeapSnapshot es muy lento. No se supone que sea rápido, ¿verdad? No necesita serlo. Así que de todos modos, tratemos de no mantener este patrón de optimizar closures demasiado en mente. Solo mantenlo en el fondo de tu mente como algo que, ya sabes, cuando te encuentres con fugas de memoria, esto es algo que querrás tener en cuenta. No es algo de lo que debas preocuparte en tu programación diaria, a menos que estés haciendo cosas realmente, realmente sensibles al rendimiento.

Usa HeapSnapshots. Simplemente experimenta con ellos, honestamente, también. Es como, son una herramienta increíblemente útil no solo para depurar fugas de memoria, sino obviamente, especialmente fugas de memoria. Y luego, cuando te encuentres con errores en tu código upstream, entonces arréglalos. Especialmente con Node.js, siempre eres bienvenido a hacerlo. Definitivamente apreciamos las contribuciones. Y luego, obviamente, porque, ya sabes, esto es 2026, necesito hablar sobre IA.

Solo por curiosidad mientras preparaba esta charla, di este ejemplo de los dos, como el setInterval y setTimeout a Claude y le pregunté, aquí está el HeapSnapshot, dime qué está mal. ¿Verdad? Y en realidad explica el problema bastante bien. Así que esos también son herramientas con las que puedes integrarte. Obviamente, no analicé todo el HeapSnapshot por mi cuenta.

Solo escribí un script que analizó el HeapSnapshot para ello. ¿Verdad? Pero luego, cuando hablas de errores en producción, ten en cuenta que estos HeapSnapshots pueden ser realmente grandes, porque no son solo copias de la memoria de tu aplicación, son como copias filtradas de la memoria de tu aplicación serializadas a JSON. Contienen tus datos, como los HeapSnapshots en realidad contienen, bueno, como la memoria de tu aplicación. Así que es muy fácil que los secretos terminen allí. Así que ten cuidado al pasar esto a agentes de IA.

Y al final del día, todavía siento que, como desarrolladores de JavaScript, es nuestro trabajo entender lo que hacen nuestras aplicaciones. Y poder depurarlas. Así que de todos modos, gracias por tu tiempo.

Y... ¿Tienes algún consejo para encontrar errores que están tan profundamente incrustados? No tengas miedo. Creo que ese es realmente el mayor consejo. Si te encuentras con problemas que son realmente complicados, siempre es una gran oportunidad de aprendizaje.

Y siento que incluso en una era en la que siempre estamos presionados para lanzar lo más rápido posible y para hacer la mayor cantidad de trabajo posible, siempre valdrá la pena tomarse el tiempo para entender lo que realmente está sucediendo. Cuando tienes la sensación de que no tienes del todo claro lo que está pasando, la mayoría de las veces vale la pena simplemente, ya sabes, bueno, voy a aprender esto. Voy a trabajar en esto hasta que lo entienda. Eso es genial.

Muchas gracias. Otra pregunta es, ¿podría el módulo Node VM ayudar con esto, ya que uno tiene control total sobre los contactos disponibles? No, porque estamos usando el módulo Node VM aquí. La única razón por la que no entré en eso, porque haría que la charla fuera cinco minutos más larga. El hecho de que en realidad estaba manteniendo vivo todo el contexto de VM también es parte del problema aquí, ¿verdad? Porque los contactos de VM todavía viven en el mismo heap, así que si quisiéramos un heap completamente separado, tendríamos que hacer algo como un hilo de trabajo, lo cual podría ser una solución potencial sí.

Bien, genial. ¿Y cuáles son algunos de los mayores desafíos que enfrentas al hacer este trabajo? Una pregunta muy amplia. Supongo que eso vuelve a mi punto anterior, como, ya sabes, si sientes que, ya sabes, no tienes el tiempo para realmente profundizar en problemas como este, eso es algo que debes, como, empujar un poco, o como, ya sabes, sí, tratar de tener en cuenta de una manera que, como, ya sabes, trabajes con quien sea tu gerente o algo, como, oye, esto es parte de lo que hacemos como ingenieros de software, ¿verdad? Y esto es parte de cómo aprendemos. No es solo, como, ya sabes, enviar cosas. Es cómo entiendes tu trabajo. Así que la justificación para tener el tiempo y los recursos para profundizar realmente en eso.

Sí, eso es interesante. La siguiente pregunta es, ¿has considerado la monitorización preventiva del tamaño del heap para prevenir cambios malignos? No de esa forma, pero como mencioné, pusimos pruebas de regresión para este tipo de problema. Como, las pruebas que añadimos realmente capturarían cualquier cosa que mantenga ese contexto x4vm que acabo de mencionar vivo, y eso ya cubriría una amplia gama de problemas. Genial.

¿Y las pruebas pasaron en el lanzamiento inicial del autocompletado sin desbordar el heap? Bueno, nosotros... Así que esto es una brecha en nuestras pruebas. Creo que podemos ser honestos sobre eso. Cuando fusionamos la función de autocompletado con el feature flag, no comenzamos a probar con el feature flag activado y desactivado. Como, solo lo teníamos en el modo predeterminado, y eso es lo que probamos. Y así, si hubiéramos probado ambas combinaciones explícitamente, probablemente no nos habríamos encontrado con esto en este formato, como, porque simplemente nos habríamos dado cuenta antes de que, oye, no podemos lanzar esto tal como está. Sí, eso es justo. Siempre es fácil con retrospectiva ver. Sí. Es solo una brecha. Sí.

Sí. ¿Y hay una forma confiable de forzar el vaciado del GC en las pruebas antes de inspeccionar el heap? Claro, sí. Entonces, quiero decir, en realidad, las cosas que mostré son formas confiables. Porque, como, si llamas a algo como v8.get heap snapshot, eso va a hacer una ejecución de recolección de basura antes, porque el serializador de snapshot del heap no quiere lidiar con tu basura. Quiere solo escribir las cosas en el disco que, ya sabes, son realmente relevantes. De lo contrario, si realmente solo quieres vaciar la recolección de basura, también puedes hacerlo. Hay una flag en Node.js, dash dash expose GC que puedes usar para, ya sabes, bueno, obtener una función GC que puedes llamar para forzarla. Pero la mayoría de las veces, probablemente no es lo que quieres. Genial. Muchas gracias. Fantástico.