Skip to main content
La livraison est au plus une fois — il n’y a pas de relecture. Ce qui a été confirmé pendant que vous étiez déconnecté n’est pas renvoyé, donc un client de production doit détecter le décalage et décider s’il doit combler cette lacune. Le signal pour cela est 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-RPC ping explicite à un intervalle plus court :
Il renvoie le slot actuel et, plus important encore, compte comme un message client pour le timer d’inactivité. Une trame de ping WebSocket au niveau de la bibliothèque ne le fait pas.

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 sur error.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.