Un client WebSocket qui rejoignait avant que le serveur ne l'autorise
Socket.io handleConnection is async and sets client.data.token only after awaiting, so a fast client reached the join handler before auth finished and found no token.
Ça ne pouvait pas marcher
Une course, un ordre, une colonne pour deux choses. La forme l'excluait avant même l'exécution.
Trouvé pendant une revue à profondeur de production, pas depuis un signalement. RealtimeGateway.handleConnection est async — il résout le jeton et seulement ensuite définit client.data.token. Mais ce déclenchement et l'action suivante du client (rejoindre une room de conversation, ce que le front-end fait immédiatement) ne sont pas ordonnés l'un par rapport à l'autre. Un client rapide pouvait atteindre handleJoin avant que le travail async ne finisse, ne trouver aucun jeton, et se faire déconnecter silencieusement sans faute de sa part.
Un test manuel au clic ne l'attraperait presque jamais, puisque la résolution finit généralement bien dans un aller-retour. Ça ferait surface comme un « parfois la messagerie ne se connecte juste pas » intermittent, ce qui est le pire genre de ticket.
handleJoin re-dérive maintenant le jeton du handshake si la valeur en cache n'est pas là. Vérifié avec un script socket.io-client autonome qui martelait la séquence rejoindre-à-la-connexion, 5/5 propres après avoir précédemment reproduit la déconnexion. Un handler de connexion async qui définit un état dont d'autres handlers dépendent est une course par construction — ça vaut la peine de demander « et si le message suivant arrive avant que cette promesse ne se résolve » à chaque fois.