khadhroony-bot3/docs/validation/WEBSOCKET_LIFECYCLE_VALIDATION_SCENARIO.md

Validation du cycle de vie WebSocket desktop

Objectif

Prouver qu’une session WebSocket appartient à l’application et non à la fenêtre demo_ws.

Préparation

1. Configurer un endpoint WebSocket Devnet dans le profil utilisé.
2. Activer une route de logs contenant au minimum kb-app-demo-desktop et kb-onchain-transport au niveau debug.
3. Lancer :

cargo tauri dev -c kb-app-demo-desktop/tauri.conf.json 2>&1 | tee /tmp/kbot3-pre075-ws.log

4. Ouvrir la fenêtre WebSocket standard.
5. Rafraîchir les endpoints et vérifier qu’un rôle compatible est disponible.

Souscription principale recommandée

Utiliser logsSubscribe, car elle permet de filtrer les transactions mentionnant un Program ID.

Champ	Valeur
Rôle	rôle WebSocket standard Devnet disponible
Méthode	logsSubscribe
Target	vide
Filter JSON	{"mentions":["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"]}
Config JSON	{"commitment":"confirmed"}

Le Program ID choisi est SPL Token classique. Il peut être remplacé par Token-2022 :

TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

Scénario A — fermeture et réouverture de la fenêtre

1. Cliquer Souscrire.
2. Noter l’identifiant de subscription et vérifier :
   • statut connecté ;
   • subscriptionCount = 1 ;
   • méthode logsSubscribe.
3. Attendre au moins une notification ou, à défaut, conserver la réponse de subscription.
4. Fermer uniquement la fenêtre demo_ws avec le bouton de la fenêtre.
5. Ne pas cliquer sur Unsubscribe ni Déconnecter socket.
6. Attendre 15 à 30 secondes.
7. Rouvrir WebSocket standard depuis le menu principal.
8. Vérifier immédiatement :
   • statut connecté ;
   • même endpoint ;
   • subscription toujours présente ;
   • même identifiant distant ou identifiant remappé explicitement après reconnexion ;
   • nouveaux messages reçus si le réseau en produit.

Critère de réussite

La fenêtre restaurée affiche l’état réel de la session persistante. Aucun événement Disconnected ne doit être provoqué par la fermeture de demo_ws.

Scénario B — unsubscribe explicite

1. Sélectionner la subscription active.
2. Cliquer Unsubscribe sélectionnée.
3. Vérifier :
   • subscriptionCount = 0 ;
   • socket encore connectée ;
   • message de désinscription ;
   • absence de nouvelles notifications pour cette subscription.

Scénario C — nouvelle subscription puis déconnexion explicite

1. Souscrire de nouveau avec le même filtre.
2. Vérifier subscriptionCount = 1.
3. Cliquer Déconnecter socket.
4. Vérifier :
   • statut déconnecté ;
   • aucune subscription active ;
   • événement ou diagnostic de déconnexion dans les logs.

Scénario D — arrêt global de l’application

1. Souscrire de nouveau.
2. Fermer la fenêtre demo_ws.
3. Fermer ensuite la fenêtre principale de l’application.
4. Vérifier dans /tmp/kbot3-pre075-ws.log que la déconnexion globale est exécutée.
5. Vérifier que le processus Tauri se termine sans rester en arrière-plan.

Scénario optionnel — programSubscribe

Pour observer les changements de comptes appartenant à Token-2022 :

Champ	Valeur
Méthode	programSubscribe
Target	TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb
Filter JSON	vide
Config JSON	{"commitment":"confirmed","encoding":"base64"}

Cette souscription peut être très active. Les limites de débit et de taille de l’interface doivent rester fonctionnelles.

Preuves à archiver

Fournir une archive contenant :

• /tmp/kbot3-pre075-ws.log ;
• copie du statut avant fermeture ;
• copie du statut après réouverture ;
• identifiants de subscription ;
• résultat unsubscribe ;
• résultat disconnect ;
• heure approximative de chaque étape ;
• anomalie éventuelle et reproduction minimale.