El bug más raro que he visto hasta ahora

Descubrimiento y proceso de resolución de un bug extraño

• Durante una guardia on-call del equipo de herramientas internas, los usuarios que usaban el software interno de Gusto experimentaron fallas del navegador Chrome.
• Este problema provocó diversas interrupciones en la atención al cliente.
• Para resolverlo, se pidió ayuda a colegas con experiencia, al equipo de infraestructura de producto y al equipo de TI.

Primera pista

• Se intentó encontrar puntos en común entre los usuarios afectados.
• No todos los empleados de Gusto se vieron afectados, y el software orientado al cliente no presentaba problemas.
• Otras páginas web del software interno funcionaban con normalidad.
• Las fallas ocurrían de forma inconsistente, y no se presentaban en Safari ni en Firefox.

Segunda pista

• Se planteó la hipótesis de que la versión de Chrome podía ser el problema.
• Parecía que el problema se resolvía para algunos usuarios al actualizar la versión de Chrome, pero no quedó completamente solucionado.
• También se sospechó que una extensión de Chrome podía ser la causa, pero el problema se reprodujo incluso sin extensiones.

Dificultad para reproducir el bug

• El equipo de infraestructura pidió a todos los ingenieros que intentaran reproducir el problema.
• Salvo dos ingenieros en Turquía, nadie del equipo de ingeniería reportó fallas.
• Como la función de reporte de fallas de Chrome estaba deshabilitada por motivos de seguridad, la resolución del problema se complicó.

Un golpe de suerte

• Un ingeniero en Denver reportó que el problema apareció después de descargar la app de escritorio de Grammarly.
• Descubrió que al eliminar la app de Grammarly y reiniciar la computadora, el problema se resolvía.

Progreso

• Una vez que fue posible depurar, se hicieron varios intentos para encontrar la causa del problema.
• La aplicación interna principal estaba construida sobre ActiveAdmin, pero las partes nuevas que usaban React no fallaban.
• Mientras se investigaba el código compartido, se descubrió que el menú desplegable My History era la causa del problema.

Resolución del problema

• Se confirmó que el archivo de imagen loader-spinner.gif estaba causando el problema.
• Al reemplazar ese GIF por otra imagen, la página dejó de fallar.
• No está claro si Grammarly o Chrome corrigieron el problema, pero ahora el GIF original ya no hace que Chrome falle.

Conclusión

• Un GIF animado inesperado terminó siendo la clave para depurar el problema.
• El problema se resolvió gracias a la curiosidad y la colaboración.
• Gusto ofrece la oportunidad de trabajar con personas colaborativas y curiosas.

Opinión de GN⁺

Lo más importante de este texto es la descripción detallada del proceso para descubrir y resolver un bug causado por un origen inesperado. El artículo muestra la complejidad y lo impredecible de la ingeniería de software, y subraya lo importantes que son el trabajo en equipo y la persistencia para resolver problemas. También ofrece un caso interesante de cómo un equipo de ingeniería colabora para resolver un problema difícil, lo que lo convierte en una historia muy atractiva para quienes se interesan por la ingeniería.

[GN⁺]

Opiniones de Hacker News

• Mientras leía, pensé que quizá era un problema relacionado con Grammarly; antes me tocó un bug con un patrón parecido: no se podía reproducir, pero afectaba a muchas personas dentro de un departamento específico.
  Al final, el punto en común era que tenían instalada la extensión de Grammarly, y ocurría solo en una URL de vista previa de staging, no en el sitio de producción.
  La causa era una expresión regular defectuosa en la extensión de Grammarly, y si el nombre de dominio superaba unos 100 caracteres, la página se congelaba.
  Si este caso de verdad fue causado por la app de escritorio, se siente todavía más aterrador.

  • Me decepcionó que el desenlace terminara en “como no podemos ver dentro de Grammarly ni de Chrome, no sabemos por qué la decodificación/renderizado del GIF provoca el crash”.
    Muchos problemas se pueden acotar hasta una combinación específica, pero si al final no se sabe por qué, no resulta satisfactorio.
  • Justo hoy estuve depurando una expresión regular que, si un usuario ingresaba un valor incorrecto en un formulario, podía poner el backend en estado de denegación de servicio.
    Por eso ahora estoy leyendo sobre motores de expresiones regulares: https://swtch.com/%7Ersc/regexp/regexp1.html
  • Hace unos 5 años me pasó algo parecido con un software de videovigilancia basado en web.
    Durante una actualización corporativa a Windows 10, reemplazamos la laptop vieja de un gerente; el proceso estaba bien armado, con revisión de requisitos del software y de red, respaldo del perfil de usuario y documentos, etc.
    En la hoja de evaluación del equipo figuraba una ThinkPad de 10 años, 4 GB de RAM y una nota que decía que se apagaba si se desconectaba el cable de corriente; me pareció admirable la paciencia de seguir usándola.
    Tras entregar la laptop nueva, casi todo funcionaba bien, salvo que no se había podido transferir la licencia de Grammarly, así que levantamos una solicitud; una semana después se aplicó la clave de licencia y confirmamos que Grammarly también funcionaba correctamente.
    Pero más tarde ese mismo día avisaron que la página web de las cámaras de seguridad se crasheaba; la mesa de ayuda probó reiniciar, borrar caché, reinstalar el navegador y recrear el perfil, pero no se resolvió y me lo escalaron.
    Revisé la red, los logs del firewall, otras PCs y accesos tanto en sitio como externos; de mi lado todo funcionaba y nadie más tenía problemas.
    Cuando pregunté “¿cambió algo recientemente en la PC o en la oficina?”, respondió en broma “hoy instalé Grammarly, ¿será eso?”; como ya no me quedaban ideas, lo desinstalamos de verdad y funcionó.
    Volvimos a activar Grammarly y al hacer clic en el enlace volvió a fallar claramente.
    Ese software de cámaras era muy viejo, y el enlace personalizado de la página de inicio tenía la pinta de una URL generada por PHP extremadamente larga; además, esa persona era la única en el lugar que usaba Grammarly, así que fue un problema que apareció una sola vez.
  • Cuando un bug de un sitio web no se resuelve fácilmente, el primer paso debería ser desactivar todas las extensiones.
    Los desarrolladores muchas veces pasan por alto que una extensión puede ser la causa, pero las extensiones pueden hacerle de todo a una página web.

• Un profesor de la universidad me dijo que, mientras escribía un paper, el subrayado no se mantenía; pensé que era un simple error de usuario y que podría ayudarlo en 5 minutos.
  Pero recién después de más de 3 horas descubrí que la combinación de una versión específica del driver de la tarjeta de video y una versión específica del driver de la impresora impedía únicamente la salida del subrayado.

  • Me parece mejor que el bug de Xerox que cambiaba números en documentos escaneados.
    https://www.zdnet.com/article/xerox-scanners-alter-numbers-i...
  • Me da curiosidad cómo lograron encontrar una combinación tan particular en apenas unas 3 horas.
  • No entiendo cómo una tarjeta de video puede afectar la impresión.

• Aunque hayan desactivado el reporte de crashes, es posible que se haya generado un archivo .dmp en algún lugar del directorio del perfil de usuario.
  Si suben manualmente ese archivo a un bug en https://crbug.com/new, los desarrolladores de Chrome podrán depurarlo.
  Si no pueden compartir el dump por razones similares a las de haber desactivado el reporte de crashes, pueden compilar minidump_stackwalk en Chromium para generar un stack trace sin símbolos y subirlo al bug.
  Entonces los desarrolladores de Chrome podrán agregarle los símbolos.
  Hay más detalles en https://www.chromium.org/developers/decoding-crash-dumps/.

• Es interesante la combinación de tecnologías que produjo este bug. La web de 2023 es exactamente así.
  Me gustaría saber si el bug de Chromium se resolvió, pero no es fácil navegar esta lista: https://bugs.chromium.org/p/chromium/issues/list?can=1&q=gif...
  También me gusta la sensación de que Gusto publicó esto para mostrar que “no fue culpa nuestra” y de paso tirarle un pequeño dardo a Grammarly.

  • Como no era un problema visible externamente, más que una cuestión de responsabilidad, parece que lo publicaron simplemente porque es una historia divertida y publicidad gratis.
  • Ese GIF sí o sí deberían publicarlo.
  • Podría haber sido este issue: https://bugs.chromium.org/p/chromium/issues/detail?id=129770...

• Había un problema en el que, después de arrancar en Linux, a veces no había sonido, y resultó que estaba relacionado con la configuración de arranque dual con Windows
  Al reiniciar desde Windows, no apagaba por completo el dispositivo de audio Realtek, sino que lo dejaba en modo de suspensión, y Linux no podía inicializar ese dispositivo
  La única solución era apagar siempre desde Windows y luego encender con el botón de encendido, y el problema aún persiste: https://askubuntu.com/questions/1032543/no-sound-in-ubuntu-1...

  • También vi un caso casi opuesto
    Una persona que hacía arranque dual con Windows y Linux solo lograba que funcionara el wifi si arrancaba en Windows y luego reiniciaba a Linux
    Como la instalación de Linux no tenía el paquete de firmware para la tarjeta wifi, al reiniciar desde Windows el dispositivo ya quedaba preparado, pero si hacía un arranque en frío directo a Linux no funcionaba
  • También pasó algo parecido en la dirección contraria. Si se reiniciaba desde Linux, Windows 10 tiraba una pantalla azul durante el arranque
  • Me pregunto si desactivar el cambio rápido de usuario tampoco lo solucionó
  • Hace unos años vi un comportamiento parecido con dispositivos Bluetooth

• Estoy de acuerdo en que el final es totalmente anticlimático
  Básicamente dice que, como no se tiene acceso ni al código fuente de Chrome ni al de Grammarly, solo se puede especular, y me pregunto si esto es resultado del movimiento de “código abierto”
  Sin código fuente, algunos desarrolladores quedan completamente perdidos y se niegan a investigar más a fondo; para las empresas que no quieren que se sepa la verdad, esa actitud debe ser muy bienvenida
  Antes había mucha gente que, aun sin el código fuente, desensamblaba programas, los entendía y los parcheaba, y muchos de ellos ni siquiera eran desarrolladores profesionales
  Simplemente tenían la motivación de hacer que el software se comportara como querían, y en el proceso aprendían naturalmente lo necesario
  El texto también toca el punto de que la complejidad de todo el stack es una locura. Al ver framework tras framework apilándose uno sobre otro, da la impresión de que buena parte del problema es autoinfligida
  Dicen que al quitar loader-spinner.gif, es decir, el placeholder que se muestra mientras se cargan las opciones del menú, la página dejó de crashear, pero también me pregunto si cargar opciones de menú tarda tanto como para necesitar una animación

  • Esperar que todos los desarrolladores puedan parchear binarios es, por decirlo amablemente, poco realista
    El mundo de la ingeniería de software es enorme, y desde hace mucho es casi imposible conocer todas las partes del stack
    Además, la ingeniería de software es un camino de aprendizaje, y cada quien está en un punto distinto de ese camino
  • Incluso cuando hay código abierto, en general parece faltar disposición real para leer el código
    Ni hablar de abrir un desensamblador o conectar un depurador; esas habilidades parece que ya casi no se enseñan
  • Probablemente haga una solicitud de red para traer las opciones del menú
    Aunque normalmente termine casi al instante, tiene sentido poner un spinner de carga por si tarda

• Lo más raro fue una vez que un usuario dijo que el texto que ingresaba en cierto formulario cambiaba al guardarlo
  Al principio pensé que otra persona estaba editando el mismo formulario al mismo tiempo, pero según los logs no era así, y en mi computadora se veía el texto correcto
  Luego noté en una captura de pantalla que algunos textos del menú también estaban raros, y la causa era que estaba activada la opción “Traducir esta página” de Chrome
  Cuando le expliqué cómo cambiar correctamente el idioma dentro de la app, el problema desapareció

  • Después de descubrir un bug en el que Chrome rompía la página, agregamos la configuración relacionada a todas las páginas de una webapp de una sola página
    Parece que este es el nuevo orden que se puede aplicar a una app o a elementos. Supongo que no es CSS porque no quieren admitir cambios dinámicos, y se ve feo: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
    A veces, al mirar las meta tags de una gran app de una sola página, descubro nuevos horrores mientras intento averiguar por qué hace falta esa etiqueta
  • Esto es realmente irritante
    Para leer sitios web en japonés suelo depender de Google Translate, pero todos los sitios web que usan React se rompen
    Es porque React y Google Translate intentan actualizar nodos del DOM sin saber el uno del otro
    Incluso llegué a mirar seriamente la implementación de Google Translate para ver si después podía volver a crear un widget web que no tuviera este problema
    [1] https://bugs.chromium.org/p/chromium/issues/detail?id=872770
  • Me pregunto si estaba traduciendo inglés a estadounidense o algo así
  • Esta historia es tan graciosa que podría mandarse a algo como DailyWTF

• Es un problema demasiado familiar
  Hace tiempo vi que las herramientas de accesibilidad de Chrome causaban este tipo de problema en menús desplegables, y se podía reproducir incluso con un HTML diminuto
  El bug específico que me tocó hace 2 años estaba en Chromium-Edge, pero los síntomas y la causa eran muy parecidos
  Grammarly casi con certeza depende de alguna parte de las herramientas de accesibilidad de Chrome
  Estas herramientas varían un poco entre los derivados de Chromium como Edge, Brave y Chrome

  • Si esta hipótesis es correcta, me pregunto si significa que Grammarly Desktop ve el GIF, de alguna manera llama a funciones de accesibilidad del navegador, y Chrome no logra manejarlo y crashea

• Recomiendo que la próxima vez que pase algo así simplemente hagan que use otro navegador
  En particular, Firefox mejoró mucho su función para importar marcadores, contraseñas y demás desde Chrome
  El universo está enviando una señal de que ya es hora de cambiarse, y no podemos rechazar las señales
  Como referencia, soy ingeniero de Firefox, pero eso no tiene nada que ver con este consejo

  • Desde el punto de vista de ingeniería, Firefox sí es una buena solución
    Desde el punto de vista de PM, uno piensa: pasamos 4 meses haciendo más fácil el onboarding, ¿y ahora vamos a pedirle a la gente que instale un navegador nuevo?
  • En el artículo enlazado ya aparece explícitamente como solución alternativa
  • Chrome tiene más de la mitad del mercado
    Que un producto basado en navegador no funcione correctamente en el navegador más usado del mundo no es una buena señal

• Me encanta la política de seguridad corporativa que bloquea los informes de fallas de Chrome por motivos de seguridad, pero permite que los empleados instalen Grammarly