El incidente se originó por un crecimiento desproporcionado del monorepo de Git de Dropbox, que pasó de un tamaño manejable a 87GB, acercándose peligrosamente al límite de 100GB de GitHub. La causa raíz no fue el volumen de código o binarios, sino una interacción inesperada entre la estructura de directorios de los archivos de internacionalización (i18n) y la heurística de compresión delta de Git. Git, por defecto, usa los últimos 16 caracteres de la ruta para emparejar archivos similares para la compresión delta. Sin embargo, la estructura de i18n de Dropbox (i18n/metaserver/[language]/LC_MESSAGES/[filename].po) colocaba el código de idioma al principio de la ruta, haciendo que Git comparara archivos de diferentes idiomas en lugar de versiones del mismo archivo en el mismo idioma. Esto resultaba en deltas mucho más grandes y menos eficientes, inflando el tamaño del repositorio con cada actualización de traducción.
Las salvaguardas existentes, como la monitorización del tamaño del repositorio, fallaron en identificar la causa raíz estructural, enfocándose inicialmente en el contenido (archivos grandes, dependencias) en lugar de cómo se almacenaba. La falta de visibilidad sobre las métricas internas de compresión de Git impidió una detección temprana del problema subyacente. Aunque se identificó una solución local con un flag experimental de Git ('--path-walk'), esta no era compatible con las optimizaciones de GitHub, lo que requirió una colaboración profunda con el proveedor de la plataforma para implementar una solución a nivel de servidor.
La cascada de fallos incluyó un aumento significativo en los tiempos de clonación (más de una hora), afectando la productividad de los ingenieros y la velocidad de los pipelines de CI. Los sistemas internos que sincronizaban el repositorio también experimentaron un mayor riesgo de timeouts y degradación del rendimiento. La proximidad al límite de 100GB de GitHub introdujo un riesgo operacional inminente de degradación de la plataforma. La resolución implicó un 'git repack' agresivo con parámetros 'window' y 'depth' ajustados, ejecutado directamente en los servidores de GitHub, lo que redujo el repositorio a 20GB y mejoró drásticamente los tiempos de clonación y la eficiencia general.