context.slot : il délimite la fenêtre que vous avez manquée lors d’une déconnexion. Ce guide explique pourquoi les connexions se ferment, comment se reconnecter proprement et comment l’utiliser.
Pourquoi les connexions se ferment
Chaque fermeture a un code de fermeture WebSocket qui vous indique ce qui s’est passé et ce qu’il faut faire ensuite :
Le serveur envoie un ping toutes les 15 secondes, donc une connexion saine mais silencieuse transporte encore du trafic. Si vous ne voyez rien du tout pendant plus d’une minute — ni notification, ni ping — supposez que la connexion est morte et reconnectez-vous plutôt que d’attendre que la socket vous informe.
Garder la connexion active
Si votre filtre est suffisamment étroit pour qu’il puisse légitimement passer 10 minutes sans correspondance, envoyez un JSON-RPCping explicite à un intervalle plus court :
Se reconnecter et détecter le décalage
1
Reconnecter avec délai
À toute fermeture — prévue ou non — reconnectez-vous avec un délai exponentiel. Les identifiants d’abonnement ne survivent pas à une reconnexion, donc renvoyez
parsedTransactionSubscribe pour chaque filtre que vous aviez ouvert.2
Suivre context.slot à travers les déconnexions
Gardez le dernier
context.slot que vous avez vu avant la déconnexion. L’écart entre ce slot et le premier slot que vous voyez après la reconnexion est exactement la fenêtre que vous avez manquée — rien de plus, rien de moins.3
Remplir les données si nécessaire
Si votre application ne peut pas tolérer le décalage, remplissez cette fenêtre de slots depuis le RPC :
getSignaturesForAddress pour énumérer les transactions dans la plage, puis getTransaction pour récupérer chacune. C’est une étape de réconciliation manuelle — Parsed Streams ne rejoue pas.context.slot est ce qui survit à une reconnexion : suivez le slot le plus élevé que vous avez entièrement traité avant la déconnexion et traitez tout ce qui vient après comme la fenêtre de remplissage.
Gestion des erreurs JSON-RPC
Les demandes qui échouent renvoient une erreur JSON-RPC au lieu d’un résultat, vous pouvez donc vous baser surerror.code :
-32602 et -32000 signifient que la demande elle-même est incorrecte — corrigez le filtre, ne le réessayez pas tel quel. -32001 et -32002 sont transitoires ; réessayez avec le même délai que vous utilisez pour les reconnexions.
Prochaines étapes
Démarrage rapide
Référence complète du protocole : méthodes, champs de filtre, limites.
Suivre les échanges Jupiter
Construisez un filtre auquel cette connexion peut s’abonner.