C’est par connexion que les bugs tombent

Je suis arrivé sur ce travail avec une refacto déjà largement écrite — soixante-dix fichiers, le passage d’une connexion « active » unique à des Connexions multiples — et une consigne simple en apparence : faire passer les tests Playwright, puis vérifier que plus rien n’était global. La partie la plus instructive n’a pas été le code de production, mais ce que les tests d’acceptance ont refusé de laisser passer.

Le premier piège était trivial et pourtant coûteux : la ligne d’une Connexion se lit maintenant connected ou disconnected, et "disconnected".includes("connected") est vrai. Le harnais croyait donc qu’un serveur déconnecté après un rechargement de fenêtre était connecté, et tout ce qui suivait échouait sur des symptômes sans rapport (un arbre sans enfants, un twistie « couvert par des lignes sticky »). J’ai passé un moment à soupçonner VS Code avant de relire une capture d’écran et d’y voir le mot entier. Leçon retenue : quand un test d’interface échoue loin de sa cause apparente, regarder l’image avant les traces.

Le second enseignement concerne l’exception qui masque l’exception. Un scénario échouait dans son finally ; l’erreur d’origine — une toast « Install now » que la refacto avait supprimée — était invisible parce que le nettoyage levait à son tour. Deux runs ont été nécessaires pour comprendre que je courais après le mauvais message.

Enfin, le vrai bug de concurrence n’était pas là où je l’attendais. La refacto avait ajouté un contrôle de capacité pldbgapi après chaque DDL ; ce contrôle émettait un événement de changement de connexion, que Schema Sync prenait pour un signal de réconciliation, voyait la base marquée « stale » par la notification qu’il venait lui-même de recevoir, et repartait sur une reconstruction complète juste avant son propre rafraîchissement incrémental. Rien de faux localement dans aucun des trois morceaux ; c’est leur composition qui l’était. La correction — distinguer un changement de capacité d’un changement de connectivité — tient en quelques lignes, mais il a fallu exposer le message des états d’index dans le snapshot d’acceptance pour la voir.

Le propriétaire du projet a poussé sur un point que j’aurais volontiers reporté : la file d’indexation unique pour toutes les Connexions. J’ai d’abord présenté cela comme « une sérialisation, pas une variable globale ». Il a demandé des précisions ; en les écrivant, la file par scope s’est imposée d’elle-même, et la revue ciblée qui a suivi a alors révélé un problème plus ancien — la génération globale du daemon utilisée comme témoin de fraîcheur d’un snapshot par Connexion — que la sérialisation cachait par accident. Un contributeur futur pourra noter que dans ce projet, « c’est par connexion » n’est pas une préférence de style : c’est le critère qui a fait tomber les bugs.