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

Muy bien. Bueno, me alegra que tanta gente esté aquí para escucharme hablar sobre JavaScript. Siempre me encanta eso. Pero sí, de todos modos, este soy yo. Puedes encontrarme en BlueSky si quieres contactarme en cualquier momento después de la conferencia. También tengo 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 poco de visión general de lo que realmente queríamos hacer. Y como sabrás si alguna vez has usado MongoDB, tenemos una 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í, nuestra CLI de base de datos se llama Mongosh. Cualquiera está bien. Y sí, puedes escribir JavaScript en esta 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 bueno si el autocompletado en nuestra CLI pudiera ser mucho más consciente del contexto y mucho más útil para nuestros usuarios? Así que, por ejemplo, si tienes este tipo de documento 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. Es como que 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. Y entonces comenzamos a tener un plan.

Y la primera idea fue, bueno, está bien, hay un autocompletador realmente bueno para JavaScript que millones de personas usan todos los días. Y todos en esta sala lo han usado miles de veces, que es el motor de autocompletado de TypeScript, ¿verdad? Esto es como lo que, por ejemplo, VS Code utiliza, pero también como un montón de diferentes entornos. Y entonces pensamos, bueno, podríamos simplemente aplicar esto a la base de datos, como a la entrada de nuestra CLI, ¿verdad? No debería ser demasiado 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 son sus documentos. Tenemos una idea bastante buena de cómo es 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 nuestra CLI, en realidad autocompleta los nombres de los campos cuando hago tap, tap dentro de la CLI. Así que encantador.

Y todo el crédito donde se debe. La mayor parte del trabajo de implementación para esto fue hecho en realidad por mi compañero de trabajo, que está sentado aquí 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 para que lo sepas. 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. Las pruebas comenzaron a fallar con errores de falta de memoria. Mientras estaban probando la parte de autocompletado de todo. Así que eso obviamente no es genial.

Bueno, ¿cómo empiezas a depurar algo como esto? 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 siempre es el primer paso. Pero cada prueba pasaba por sí sola. Esto obviamente era algo que estaba sucediendo porque estábamos ejecutando pruebas en combinación. Esto hace que sea más complicado. De todos modos, todavía podemos intentar minimizar cuánto tiempo lleva hasta que lleguemos a esto. Por ejemplo, con Mocha, que es el ejecutor de pruebas que todavía usamos felizmente, nunca realmente he sentido la necesidad, personalmente, de cambiar a una de las cosas nuevas, geniales y sofisticadas. Todos me parecen prácticamente iguales, de todos modos.

Pero de todos modos, con Mocha, puedes pasar banderas de Node.js a la instancia real de Node.js. Así que lo primero que puedes intentar es simplemente reducir el tamaño del heap. Entonces, el tamaño del heap es como, ya sabes, 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? No es un bloqueo. Y de alguna manera necesitamos ver qué hay realmente en la memoria aquí, ¿verdad?

Y así, personas inteligentes, creo, de hecho, esta primera bandera que mencioné aquí, esta instantánea de 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 de heap en OEM, y básicamente está diciendo a Node.js, está bien, bueno, si te encuentras con errores de falta de memoria antes de bloquearte, 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 de 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á en algún lugar allá arriba en el número cinco. Pero también puedes ver que hay grupos de objetos que ya puedes decir. Hay muchos objetos que juntos ocupan 640,000 kilobytes en la memoria. Y eso probablemente significa que simplemente se están manteniendo vivos entre sí y esta herramienta no puede realmente 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 sistema / contexto. Y como 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 grupo que haya, como el objeto global, por ejemplo, que podría ser uno o como un socket de red. Esos serían rutas de recolección de basura. Pero sí, entonces 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. Así que solo piensa en casos muy, muy simples de retención de memoria. Creo que este es como el más simple que hay, ¿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 trozo realmente grande de memoria que está garantizado que aparecerá, como luces de Navidad en una instantánea de heap. Y si miramos la instantánea de heap para esto, resulta ser cierto. Como, 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 lo que esperarías. Así es como lees estas instantáneas de heap cuando las inspeccionas en DevTools. Así que sí, 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 ello.

Pero quizás vayamos por un ejemplo más complicado, ¿verdad? Así que, de nuevo, asignamos un gran trozo de memoria que está principalmente allí para aparecer como un gran trozo de memoria cuando lo inspeccionamos. Y programamos un intervalo que registra "done" 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 todavía tomamos una instantánea después de que ese timeout ha corrido.

Podemos ver que todavía hay algo que mantiene vivo este blob realmente grande. Y es el contexto en la función A, no en la función B. Así que el contexto, como podemos inferir de esto, 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 por lo tanto, realmente no es obvio, como, ¿qué captura esta función A? 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 blob realmente grande indefinidamente, aunque al menos en teoría un motor podría decir que nunca será accedido de nuevo.

Y eso nos acerca un poco más 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í, cuatro. Gracias. ¿Qué imprime esto? ¿Alguna idea? Sí, cuatro. ¿Qué imprime esto? ¿Alguna idea? Sí, cuatro. ¿Qué imprime esto? ¿Alguna idea? ¿Alguna idea? Sí, cuatro. ¿Alguna idea? Sí, cuatro. ¿Qué imprime esto? ¿Alguna idea? ¿Alguna idea? Sí, cuatro. ¿Qué imprime esto? ¿Alguna idea? No, no cuatro. ¡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 eval global, que es lo que obtienes cuando ejecutas eval eval, no obtienes el ámbito exterior. Y por lo tanto, 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 a, entre paréntesis, uno y final 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 realmente los errores y las correcciones con las que nos encontramos aquí.

Y así, obviamente, hubo algunas cosas innecesariamente tontas que aprendimos cuando arreglamos esto. Una es, como, está bien, entonces hay una 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í, duh, eso va a filtrar tu memoria. Pero luego, sí, también es realmente difícil de detectar, y eso es un poco como las cosas de las que estaba hablando, ¿verdad? Obviamente hay esta línea extra, que también es parte del problema aquí, pero, como, reemplazar eval con esta función eval sin contexto, y eval sin contexto es realmente solo eval puesto en un archivo separado para que no pueda capturar ninguna variable. Eso es todo. Ese es el núcleo del error que arreglamos 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 estaba realmente 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 arreglando. 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 oyente de prepaint, 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, como, llevar esto al nivel superior para que no, no sea el cierre que captura la instancia real de REPL que lo añade más. Es una cosa 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 arreglar esto.

Así que, de todos modos, y llegando al cierre de esto, podrías preguntarte, ¿cómo pruebas realmente esto? Obviamente arreglamos todos estos errores y luego nuestro CI estaba en verde, pero, como, ¿cómo te aseguras de que no retrocedes en esto, verdad? Eso es complicado. Porque, como, obviamente aún podrías, ya sabes, notar si las cosas van realmente mal, e 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 no es tan nuevo, esto es, como, de hace un par de años en este punto, pero, como, ahora hay algo llamado registro de finalización en JavaScript. Y usarlo es increíblemente difícil. Y yo... O no usarlo, usarlo correctamente es increíblemente difícil. Usarlo es bastante fácil, en realidad. Pero sí, así que 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. Hay objetos de consulta Vieta, lo cual es bastante genial. Te animaría a probarlo, 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í, esto es, como, una manera fácil de saber si, ya sabes, 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 tendríamos que mantener también el constructor, ¿verdad? Y eso fue demasiado complicado para nosotros hacerlo correctamente. Y luego está, como, la función V8 getHeapSnapshot, que es simplemente, como, te da el HeapSnapshot completo en el formato que mostré aquí. Y abierto en Chrome DevTools. Y esto es lo que usamos. Terminamos usando el registro de finalización y getHeapSnapshot y analizamos el HeapSnapshot programáticamente como parte de nuestra prueba. Es un poco de código extra, pero no es un formato tan complicado.

Así que eso es realmente bastante factible. Pero para esos, especialmente, ten en cuenta que son solo herramientas de diagnóstico. No los uses en producción. No los 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, como, ya sabes, optimizar cierres demasiado en mente. Solo mantenlo en el fondo de tu cabeza como algo que, ya sabes, cuando te encuentres con fugas de memoria esto es algo que querrás buscar. 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. Solo juega con ellos, honestamente, también. Es como si fueran 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 set interval y set timeout a Claude y le pregunté, está bien, aquí está el Heapsnapshot. Dime qué está mal. ¿Verdad? Y en realidad explica el problema bastante bien.

Así que esas también son herramientas con las que puedes integrarte. Obviamente no analizó todo el Heapsnapshot por sí solo. Solo escribió 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. 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. Hazlo bajo tu propio riesgo y entiende, ya sabes, qué exactamente estás haciendo. Además, ten cuidado al compartir esto cuando estés, ya sabes, reportando errores o algo así.

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... Aplausos. ¿Tienes algún consejo para encontrar errores que están tan profundamente incrustados? No tengas miedo. Creo que ese es realmente el mayor consejo. Como, si te encuentras con problemas que son realmente complicados, ya sabes, eso siempre es una gran oportunidad de aprendizaje. Y siento que incluso en una era donde 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.

Como 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 NodeVM ayudar con esto? Ya que uno tiene control total sobre los contextos disponibles? No, porque estamos usando el módulo NodeVM aquí. Como la única razón por la que no entré en eso es porque haría la charla cinco minutos más larga. Pero el hecho de que en realidad estaba manteniendo vivo todo el contexto de VM también es parte del problema aquí. ¿Verdad? Como si nosotros... Porque el contexto de VM todavía vive en el mismo heap.

Entonces, si quisiéramos un heap completamente separado, tendríamos que hacer algo como un worker thread, lo cual podría ser una solución potencial real. Sí. Bien, genial. ¿Y cuáles son algunos de los mayores desafíos que enfrentas al hacer este trabajo? Pregunta muy amplia. Supongo que eso vuelve a mi punto anterior. Si sientes que no tienes tiempo para profundizar realmente en problemas como este, eso es algo contra lo que necesitas empujar un poco o tratar de compensar de una manera que trabajes con quien sea tu gerente o algo así. Esto es parte de lo que hacemos como ingenieros de software, ¿verdad? Y esto es parte de cómo aprendemos. No es solo como enviar cosas, también es como 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? ¿Monitorización del tamaño del heap para prevenir cambios malignos? No en esa forma, pero como mencioné, pusimos pruebas de regresión para esta clase de problema en su lugar. 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? Así que este es un vacío en nuestras pruebas. Creo que podemos ser honestos sobre eso cuando fusionamos la función de autocompletado con la bandera de función, no comenzamos a probar con la bandera de función activada y desactivada. 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 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 un vacío. Sí.

Sí. ¿Y hay una manera 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 algo como v8.getheapsnapshot eso va a hacer una recolección de basura justo antes porque el serializador de snapshot del heap no quiere lidiar con tu basura. Quiere solo escribir las cosas que son realmente relevantes. De lo contrario, si realmente solo quieres vaciar la recolección de basura, también puedes hacerlo. Hay una bandera 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. Bien. Genial. Muchas gracias. Eso es fantástico. Gracias a todos.