Un exingeniero de Google cuenta cómo fue su guerra contra el peor error de Google Docs. Lo arregló tras dos días de infarto
Publicado el 02/04/2025 por Diario Tecnología Artículo original
En el 'mundillo' del desarrollo de software, hay 'bugs' que se corrigen con facilidad, otros que exigen ingenio... y luego están aquellos que se convierten en auténticas leyendas internas. Esta es la historia de uno de esos casos, acaecido nada menos que en Google Docs, su alternativa web a MS Office: un bug tan grave como misterioso, que provocó dolores de cabeza durante varios días a ingenieros experimentados, y cuya causa, realmente, no se encontraba en Google Docs.
El misterio fantasma
Jacob Voytko, exingeniero de Google, lo ha relatado en su propia newsletter: todo comenzó durante una rutina semanal en el equipo de Google Docs, la revisión y asignación aleatoria de nuevos los errores detectados.
Pero ese día, un problema sobresalía del resto. Se trataba de un error fatal que impedía a los usuarios editar documentos sin recargar la página. No parecía estar vinculado a ninguna actualización reciente de Docs, y lo más inquietante: era exclusivo de Chrome, pero los usuarios del mismo no se estaban quejando en masa.
La incertidumbre era total. ¿Estaba realmente ocurriendo el fallo? ¿O era solo un falso positivo en los registros?
Un 'bug' sin rostro
Los primeros intentos de replicar el error en entornos de desarrollo resultaron fallidos: ningún usuario del propio Google lo había experimentado. Se probaron combinaciones de funcionalidades y se copiaron y pegaron contenidos extraños desde sitios web, sin resultados.
Pero finalmente, apareció una pista. Usando una herramienta de scripting interna, originalmente pensada para benchmarking, nuestro ingeniero automatizó la edición de un documento de 50 páginas repleto de texto Lorem ipsum. La acción: aplicar y quitar negritas a todo el documento 100 veces. Alrededor del ciclo 20, el error finalmente emergió.
Pero no todo eran buenas noticias. El fallo era no determinista: a veces aparecía en el ciclo 10, otras en el 40, y en ocasiones no ocurría en absoluto. En resumen, un verdadero dolor de cabeza para cualquier depurador.
En busca del origen
Pronto se sospechó que el problema podía estar relacionado con el ajuste dinámico de líneas en el documento. En muchos tipos de letra, el texto en negrita no solo cambia de grosor visual, sino también de ancho real, lo que afecta directamente el modo en que las palabras se distribuyen y ajustan dentro de un párrafo. Al aplicar y quitar repetidamente el formato de negrita sobre bloques de texto extensos, se generaban sutiles alteraciones en el flujo del contenido.
Estos cambios, aparentemente inofensivos, tenían un impacto acumulativo sobre el diseño de página de Google Docs, y exigía que el motor de visualización realizara cálculos de layout en tiempo real para cada interacción del usuario. Así, el uso prolongado del script automatizado reveló que, tras múltiples ciclos de formateo, alguna parte del sistema comenzaba a registrar valores incorrectos.
Cuando el motor de vista intentaba acceder a esos valores mal almacenados, creyendo que eran válidos, y trataba de operar sobre ellos, era cuando todo se desmoronaba. Era un efecto dominó que terminaba obligando al usuario a recargar el documento.
Para entonces, era evidente que se trataba del peor escenario posible para un error:
- Reproducible solo con secuencias largas y lentas.
- No determinista.
- Originado por corrupción de caché acumulada en tiempo.
- Y lo peor: en una parte del código que el ingeniero apenas conocía.
Cuando las matemáticas (de JavaScript) mienten
Fue necesaria la ayuda de otro compañero con experiencia en la aplicación: dedicaron dos días a mover los puntos de ruptura una y otra vez, retrocediendo en el flujo de ejecución como detectives en busca del momento exacto en que todo se descarrilaba.
La revelación clave llegó tras horas de examinar meticulosamente un fragmento de código responsable de actualizar un acumulador, una variable crítica que iba sumando pequeñas diferencias para mantener la coherencia visual del documento. A simple vista, la lógica parecía inofensiva: tomar un valor, aplicar la función de JavaScript 'Math.abs()' para asegurarse de que siempre fuera positivo, y luego añadirlo al total acumulado.
Sin embargo, algo no cuadraba. Los resultados finales del acumulador no coincidían con lo esperado, incluso después de revisar varias veces las entradas y salidas. Fue entonces cuando uno de los ingenieros decidió echar un vistazo al valor devuelto por la función matemática justo antes de que fuera utilizado. Y ahí surgió lo impensable: 'Math.abs()' estaba devolviendo números negativos.
La función que, por definición, debía retornar el valor absoluto —es decir, siempre positivo— estaba violando una de las garantías básicas del lenguaje. Y al repetir el experimento varias veces, la anomalía persistía: los números negativos entraban… y salían como negativos.
El equipo, incrédulo, se sumió en una revisión casi paranoica: confirmaron que 'Math.abs()' no había sido sobrescrita de algún modo. Y no, todo era "normal", aunque claramente no lo era. Tras muchas comprobaciones, se confirmó la locura: la función estaba funcionando mal… pero solo en esa versión específica de Chrome.
El villano oculto
Rápidamente, se contactó con los desarrolladores del equipo de V8, el motor de JavaScript de Chrome. La respuesta fue tan reveladora como frustrante: el problema ya había sido identificado y corregido semanas antes. La causa se debía a que, durante una refactorización, alguien había omitido definir correctamente el comportamiento de 'Math.abs()' y, en lugar de devolver el valor absoluto, por accidente, devolvía el mismo número que recibía.
Un error sutil y difícil de detectar, ya que solo se activaba en circunstancias muy específicas y, además, ofrecía resultados técnicamente correctos la mitad del tiempo: cuando el número ya era positivo.
Así que, finalmente, el equipo de Google Docs tuvo que limitarse a aplicar un parche temporal que verificaba específicamente la versión problemática de Chrome, y que desapareció del código una vez que el número de usuarios que mantenían instalada esa versión fue lo suficientemente bajo:
"Ahí lo tienes: dos días para encontrar un problema que ya se había solucionado y que se habría resuelto sin interacción".
Imagen | Marcos Merino mediante IA
utm_campaign=02_Apr_2025"> Marcos Merino .