Le système de connexion résiliente dans QoreDB : health checks et reconnexion SSH

Une connexion à une base de données peut tomber pour des dizaines de raisons : timeout réseau, coupure du tunnel SSH, redémarrage du serveur, bascule de failover. Un client de base de données desktop qui ignore ce problème laisse l'utilisateur face à des erreurs cryptiques au moment où il exécute une requête.

QoreDB adopte une approche proactive : un monitor de santé tourne en arrière-plan et surveille chaque session active, toutes les 30 secondes. Quand une connexion décroche, le client le détecte, tente de la restaurer, et informe l'interface en temps réel.

Le SessionManager : source unique de vérité

Toutes les sessions actives sont gérées par le SessionManager, un composant Rust dans le crate qore-drivers. C'est lui qui stocke l'état de chaque connexion ouverte : le driver utilisé, la configuration, le tunnel SSH éventuel, le tunnel proxy, et le statut de santé courant.

Chaque session est identifiée par un UUID et maintient un compteur de défaillances consécutives (consecutive_failures). Ce compteur ne se réinitialise qu'en cas de ping réussi.

Trois états de santé sont possibles : healthy, unhealthy, et reconnecting. Ce dernier indique qu'une tentative de reconnexion du tunnel SSH est en cours.

Le cycle de health check : tunnel d'abord, ping ensuite

La méthode run_health_check est appelée par une tâche Tokio toutes les 30 secondes. Pour chaque session active, elle procède en deux étapes ordonnées.

La première est une vérification TCP du tunnel SSH, s'il y en a un. QoreDB tente une connexion TCP sur le port local du tunnel et vérifie qu'elle réussit. Si elle échoue, le tunnel est considéré comme mort. Cette vérification est délibérément légère : pas d'échange de protocole SSH, juste un test d'accessibilité du port.

Si le tunnel est actif (ou absent), QoreDB envoie un ping au driver. Le timeout de ping est fixé à 5 secondes. Chaque driver implémente la méthode ping selon sa propre sémantique : requête SELECT 1 pour PostgreSQL, ping natif pour MongoDB, etc. En cas d'échec, le compteur de défaillances consécutives s'incrémente.

La reconnexion automatique du tunnel SSH

Quand le tunnel est mort et que le compteur de défaillances consécutives atteint le seuil de 2, QoreDB tente une reconnexion. La session passe d'abord en état reconnecting, ce qui est immédiatement notifié au frontend. Puis le tunnel est rouvert en utilisant la même configuration SSH stockée dans la session.

Si la reconnexion réussit, l'ancien tunnel est fermé en best effort, le nouveau prend sa place, le compteur est réinitialisé à 0 et la session repasse en healthy. Si la reconnexion échoue, la session reste en unhealthy et le monitor réessaiera au prochain cycle.

Ce mécanisme couvre le cas d'usage le plus fréquent : un tunnel SSH coupé après une longue inactivité, ou à la suite d'une déconnexion réseau temporaire.

Ce que l'interface reçoit

Le backend émet des événements Tauri (connection_health) à chaque changement de statut. Le SessionProvider React écoute ces événements et met à jour l'état de santé affiché dans la barre de statut.

Quand une connexion passe en unhealthy, une notification toast s'affiche. Quand elle repasse en healthy - après reconnexion automatique du tunnel par exemple - une notification de succès confirme la restauration. L'utilisateur n'a rien à faire.

La commande check_connection_health est également exposée comme commande Tauri, ce qui permet un ping manuel à la demande depuis l'interface.

Conclusion

La résilience de connexion dans QoreDB repose sur un monitor de fond léger, un état de santé à trois niveaux, et une logique de reconnexion SSH automatique. L'objectif est d'éviter que l'utilisateur découvre une connexion morte au moment d'exécuter une requête. Le contexte desktop rend ce mécanisme plus simple à mettre en place qu'un backend partagé : il n'y a pas de concurrence entre utilisateurs, pas de coordination distribuée, juste un process local qui surveille ses propres connexions.