El incidente se originó por una desincronización sutil en la negociación de capacidades del protocolo MySQL entre los componentes de Hyperdrive (Client y Endpoint) y el Worker del usuario. Hyperdrive actúa como un proxy, siendo cliente para la base de datos de origen y servidor para el Worker. Durante la fase de conexión, Hyperdrive negocia un conjunto fijo de capacidades con la base de datos de origen, mientras que el Worker puede negociar un conjunto diferente de capacidades con Hyperdrive. Esto requiere que Hyperdrive traduzca las respuestas de la base de datos a las capacidades esperadas por el Worker.
La causa raíz específica fue una suposición errónea en el código de caching del Hyperdrive Client. Se asumió que los bytes de respuesta podían ser cacheados exactamente como se enviaban al Worker. Sin embargo, debido a la traducción de capacidades, los bytes enviados al Worker (codificados para las capacidades del Worker) eran diferentes de los bytes que Hyperdrive usaría internamente (codificados para las capacidades de Hyperdrive). Cuando el Client y el Endpoint compartían una caché (en el mismo data center), y uno leía un valor cacheado por el otro, se producía una inconsistencia. Por ejemplo, si el Endpoint cacheaba una respuesta en su formato interno y el Client la leía, el Client la enviaba directamente al Worker sin la traducción necesaria, resultando en respuestas vacías o cuelgues.
Las salvaguardas fallaron debido a la naturaleza esporádica y de bajo volumen del error (0.001%), lo que dificultó la obtención de trazas completas de ejecución. Además, la complejidad del protocolo MySQL y la interacción de múltiples capas de traducción de capacidades (Worker -> Hyperdrive Client -> Hyperdrive Endpoint -> Origin DB) ocultaron el problema. La telemetría inicial no pudo identificar la causa raíz directamente, requiriendo un análisis profundo del protocolo y una revisión exhaustiva del código de caching.
Este incidente subraya la importancia de una comprensión granular de los protocolos de red y las implicaciones de las transformaciones de datos en sistemas distribuidos. La suposición de que los datos son idénticos a través de diferentes puntos de vista del protocolo, incluso si lógicamente representan lo mismo, puede llevar a fallos difíciles de diagnosticar.