Passer au contenu principal
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.

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