El incidente se originó por una interacción inesperada entre la estructura de directorios del monorepo de Dropbox y la heurística de compresión delta por defecto de Git. Específicamente, los archivos de internacionalización (i18n) con rutas como 'i18n/metaserver/[language]/LC_MESSAGES/[filename].po' hacían que la heurística de Git, que se basa en los últimos 16 caracteres del path, emparejara archivos de diferentes idiomas para la compresión. Esto resultaba en deltas ineficientes y de gran tamaño, causando un crecimiento desproporcionado del repositorio de 20-60MB/día, hasta alcanzar los 87GB y acercarse al límite de 100GB de GitHub.
Las salvaguardas fallaron porque el crecimiento no se debía a un aumento en el volumen de commits o archivos grandes, sino a un problema estructural en cómo Git almacenaba los datos. Las herramientas de monitoreo iniciales probablemente se centraron en el tamaño total o el número de objetos, sin profundizar en la eficiencia de la compresión. La falta de visibilidad sobre las métricas internas de Git (como la eficiencia de los pack files o el tamaño de los deltas) impidió una detección temprana del problema subyacente. La asunción implícita de que Git manejaría la compresión de manera óptima para cualquier estructura de repositorio fue incorrecta en este caso particular.
La cascada de fallos incluyó tiempos de 'clone' excesivos (más de una hora), ralentización de los pipelines de CI que requerían clones frescos, mayor probabilidad de timeouts en sistemas internos que sincronizaban el repositorio y un riesgo operacional significativo al acercarse al límite de tamaño de GitHub. La solución requirió una colaboración profunda con GitHub, ya que la optimización de la compresión debía realizarse en sus servidores para ser efectiva y compatible con sus propias optimizaciones de rendimiento. La implementación se trató como un cambio de infraestructura crítica, con pruebas en mirrors y un despliegue gradual para mitigar riesgos.