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.
Filtres peu actifs et délai d’inactivité
Si votre filtre est suffisamment restrictif pour pouvoir légitimement rester 10 minutes sans correspondance, attendez-vous à ce que le serveur ferme la connexion avec le code 1000. Traitez cette fermeture comme n’importe quelle autre : reconnectez-vous, réabonnez-vous et récupérez les données manquantes comme décrit ci-dessous.Se reconnecter et détecter les données manquantes
1
Reconnect with Backoff
Après toute fermeture, prévue ou non, reconnectez-vous avec un délai exponentiel. Les identifiants d’abonnement ne persistent pas après une reconnexion. Renvoyez donc
parsedTransactionSubscribe pour chaque filtre que vous aviez ouvert.2
Track context.slot Across Disconnects
Conservez le dernier
context.slot observé avant la déconnexion. L’intervalle entre ce slot et le premier slot observé après la reconnexion correspond exactement à la fenêtre manquée, ni plus ni moins.3
Backfill if You Need To
Si votre application ne peut pas tolérer cette interruption, récupérez cette fenêtre de slots depuis RPC : utilisez
getSignaturesForAddress pour répertorier les transactions de la plage, puis getTransaction pour récupérer chacune d’elles. Il s’agit d’une étape de rapprochement manuelle : Parsed Streams ne rejoue pas les données.context.slot est ce qui persiste après une reconnexion : suivez le slot le plus élevé que vous avez entièrement traité avant la déconnexion et considérez tout ce qui le suit comme la fenêtre de récupération des données manquantes.
Gestion des erreurs JSON-RPC
Les requêtes qui échouent renvoient une erreur JSON-RPC au lieu d’un résultat. Vous pouvez donc effectuer un branchement selonerror.code :
-32602 et -32000 indiquent que la requête elle-même est incorrecte : corrigez le filtre, ne la renvoyez pas telle quelle. -32001 et -32002 sont des erreurs temporaires ; réessayez avec le même délai exponentiel que pour les reconnexions.
Étapes suivantes
Quickstart
Référence complète du protocole : méthodes, champs de filtre et limites.
Track Jupiter Swaps
Créez un filtre auquel cette connexion peut s’abonner.