Le WebSocket Tradovate se ferme exactement au bout de 5 minutes

Quand vous automatisez des valeurs rapides comme ES ou NQ, peu de choses font plus mal qu'un WebSocket Tradovate qui meurt sur un minuteur. Vous vous connectez, autorisez, vous abonnez aux données de marché, et tout se diffuse à merveille, jusqu'à 300 secondes pile, quand le socket tombe sans erreur, sans motif de fermeture, sans avertissement. C'est chaque fois la même histoire : la connexion se ferme exactement au bout de 5 minutes, même quand vos heartbeats semblent partir correctement. Deux erreurs liées accompagnent généralement ce phénomène, une exception WebSocket is not open: readyState 0 (CONNECTING) quand votre code écrit sur un socket à moitié ouvert, et un simple code de fermeture 1006 (fermeture anormale) de la part du pair distant. Voici ce que signifie réellement la fermeture à 5 minutes en 2026, les vraies causes derrière, et le schéma exact heartbeat plus reconnexion qui maintient la connexion en vie, ainsi que la façon dont PickMyTrade gère cette tuyauterie pour vous afin qu'un socket tombé ne vous coûte jamais une exécution.

Ce que signifie « le WebSocket se ferme exactement au bout de 5 minutes »

L'API temps réel de Tradovate est une connexion WebSocket : vous l'ouvrez, envoyez une trame d'autorisation, puis vous abonnez aux données et événements qui vous intéressent. Pour que cette connexion reste ouverte, le client est chargé d'envoyer des heartbeats, de petites trames de keep-alive, à cadence fixe. Cessez de les envoyer et Tradovate considère le socket comme inactif, puis le ferme côté serveur.

Si l'échec tombe si souvent sur la marque nette des 5 minutes, c'est que les délais d'expiration le long du chemin réseau, le serveur, un répartiteur de charge ou un proxy intermédiaire, ont tendance à être appliqués sur des chiffres ronds. La connexion se coupe exactement toutes les 5 minutes (300 secondes) sans message, et, fait révélateur, sans heartbeats, la coupure survient plutôt au bout d'environ 2 minutes. Les heartbeats prolongent donc la vie du socket, mais un heartbeat en retard ou manquant, ou un minuteur d'inactivité indépendant quelque part sur le chemin, peut encore le guillotiner à 300 secondes. Il n'existe pas de cause racine publiée pour le cas exact des 5 minutes ; la réponse d'ingénierie durable n'est donc pas d'empêcher chaque fermeture, mais d'y survivre.

Les deux messages d'erreur que vous verrez sont des symptômes du même problème sous-jacent. WebSocket is not open: readyState 0 (CONNECTING) signifie que votre code a tenté un send() avant la fin du handshake, ce qui arrive souvent dans une fonction de heartbeat qui se déclenche en pleine reconnexion. Le code de fermeture 1006 est la façon dont le navigateur ou la bibliothèque dit “la connexion est tombée de manière anormale”, sans handshake de fermeture propre, exactement ce que vous obtenez quand un minuteur d'inactivité côté serveur coupe la ligne.

Principales causes de la fermeture du WebSocket à 5 minutes en 2026

1. Trames de heartbeat tardives ou totalement absentes

C'est la cause numéro un. Tradovate attend une trame de heartbeat, de contenu texte [], environ toutes les 2,5 secondes pour prouver que le client est vivant. Manquez cette fenêtre et le serveur lance le compte à rebours de fermeture. Et voici le piège : dès que vous diffusez des cotations en temps réel, le serveur Tradovate cesse d'envoyer ses propres heartbeats, vous ne pouvez donc pas compter sur le trafic intégré de la connexion pour la maintenir ouverte. Votre client doit envoyer la trame de crochets vides à son propre rythme.

2. Bridage des minuteurs du navigateur (setInterval / setTimeout)

Si vous planifiez les heartbeats avec setInterval() ou setTimeout() dans un navigateur, vous êtes à la merci de la priorité de l'onglet. Quand l'onglet perd le focus, Chrome (et la plupart des navigateurs) abaisse la priorité de ces minuteurs, si bien qu'un intervalle de “2,5 secondes” peut discrètement s'étirer sur plusieurs secondes. Le heartbeat dépasse l'échéance et le socket se ferme, souvent autour de la marque des 5 minutes, une fois assez de retard accumulé.

3. Délai d'inactivité ou de session côté serveur

Même un heartbeat parfaitement cadencé ne peut pas annuler un délai d'expiration appliqué en amont. Un proxy, une passerelle ou la session Tradovate elle-même peut plafonner la durée d'inactivité ou la durée totale de connexion, ce qui explique pourquoi la fermeture tombe sur cette frontière suspecte de 300 secondes. Comme cela échappe à votre contrôle, la solution est la reconnexion, pas la prévention.

4. Envoi sur un socket qui n'est pas OPEN (readyState 0)

Un WebSocket a quatre états : CONNECTING (0), OPEN (1), CLOSING (2) et CLOSED (3). Si votre boucle de heartbeat ou votre code d'ordres appelle send() alors que le socket est encore à readyState 0, vous obtenez WebSocket is not open: readyState 0 (CONNECTING) et, souvent, un message “Disconnected from Tradovate Market WebSocket” juste derrière. C'est ce qui frappe le plus fort juste après une coupure, quand votre reconnexion a lancé un nouveau socket qui n'a pas encore terminé son handshake.

5. Expiration du jeton et connexions de longue durée

Un jeton d'accès Tradovate a une durée de vie limitée, et ces connexions ne sont pas conçues pour vivre éternellement ; maintenez un même socket ouvert très longtemps (plus d'une journée) et il a tendance à tomber. Si votre jeton expire en pleine session ou si la connexion vieillit, le socket se ferme et toute réautorisation avec l'ancien jeton échoue. La durée de vie des jetons varie et évolue avec le temps ; confirmez donc les valeurs actuelles dans la documentation API de Tradovate et renouvelez de façon proactive plutôt que d'attendre un échec.

Comment corriger la fermeture du WebSocket à 5 minutes : pas à pas

Solution 1 : envoyer une trame de heartbeat environ toutes les 2,5 secondes

Le heartbeat est le fondement. À une cadence d'environ 2,5 secondes, envoyez une trame dont le texte est un tableau JSON vide :

Solution 2 : remplacer setInterval par une vérification d'horodatage ou un Web Worker

Comme les minuteurs du navigateur sont bridés, ne vous appuyez pas sur setInterval seul, que l'onglet soit au premier plan ou en arrière-plan. Deux alternatives éprouvées :

• Heartbeats pilotés par horodatage. Enregistrez un horodatage (new Date()) chaque fois que vous recevez un message. Comparez-le à la dernière fois où vous avez envoyé un heartbeat ; si plus de 2500 ms se sont écoulées, envoyez [] immédiatement. Cela réagit au trafic réel plutôt qu'à un minuteur que le navigateur peut priver de ressources.
• Déplacez le minuteur hors du thread principal. Exécutez le heartbeat dans un Web Worker, ou exécutez toute la connexion comme un service Node.js. Les deux contournent entièrement le bridage des onglets du navigateur, un processus Node n'est pas du tout soumis à la pénalité des onglets en arrière-plan.

Solution 3 : protéger chaque envoi par une vérification de readyState

Supprimez l'erreur readyState 0 en n'écrivant jamais sur un socket qui n'est pas ouvert :

Solution 4 : ajouter une logique de reconnexion, de réautorisation et de réabonnement

Comme certaines fermetures à 5 minutes sont imposées en amont et ne peuvent pas être évitées, traitez chaque coupure comme une erreur récupérable et reconstruisez automatiquement :

Tableau de dépannage

Évitez cela avec PickMyTrade

PickMyTrade se place entre vos alertes TradingView et Tradovate et exécute la couche WebSocket comme un service géré côté serveur, de sorte que la fermeture à 5 minutes est traitée avant même de vous atteindre :

• Heartbeats gérés, envoie la trame de keep-alive à une cadence fiable côté serveur, sans onglet de navigateur pour brider le minuteur.
• Auto-Reconnect & Re-Auth, détecte un socket tombé, en ouvre un nouveau, réautorise avec un jeton valide et se réabonne automatiquement.
• Garde-fous d'état de connexion, ne transmet que lorsque le socket est réellement ouvert, éliminant les erreurs d'envoi readyState 0.
• Multi-Account Sync, maintient le flux de chaque compte connecté en bonne santé afin qu'une seule reconnexion ne laisse jamais un compte à la traîne.