Présentation du problème
Une équipe de développement a rencontré un bug non déterministe dans leur code, qui se manifestait par des tests flaky. Les tests étaient instables et présumaient une corruption de données, mais les outils de débogage classiques ne permettaient pas de comprendre pourquoi cette corruption se produisait.
Contexte technique
Le bug a été découvert après une mise à jour de la gemme Redis, qui n'avait pas entraîné de problèmes de production apparents. Cependant, les tests ont commencé à échouer de manière aléatoire, ce qui a conduit l'équipe à investiguer les causes possibles. Les tests utilisaient RSpec, Selenium et un environnement de test composé d'un serveur web, d'une base de données et d'un serveur Redis.
Investigation et débogage
L'équipe a d'abord cru que les tests étaient flaky en raison d'une condition de course entre les différents composants. Cependant, après avoir éliminé cette possibilité, ils ont découvert que le problème était lié à l'interaction entre ActionCable et Redis. En ajoutant des journaux supplémentaires, ils ont constaté que la commande de souscription était livrée à ActionCable mais n'était pas reçue par Redis.
Implémentation de la solution
Grâce à l'utilisation de l'outil AddressSanitizer (ASAN), l'équipe a pu identifier une faille d'utilisation après libération (use-after-free) dans la gemme Redis. Cette faille se produisait lorsque le thread lecteur libérait le tampon d'écriture. La solution a consisté à corriger cette faille en modifiant le code de la gemme Redis pour éviter l'utilisation après libération.
