context.slot: Es grenzt das Fenster ein, das du während eines Verbindungsabbruchs verpasst hast. Dieser Leitfaden erklärt, warum Verbindungen geschlossen werden, wie du sie sauber wiederherstellst und wie du dieses Signal verwendest.
Warum Verbindungen geschlossen werden
Jede geschlossene Verbindung hat einen WebSocket-Schließcode. Er zeigt dir, was passiert ist und was du als Nächstes tun solltest:
Der Server sendet alle 15 Sekunden einen Ping. Daher überträgt selbst eine fehlerfreie, aber inaktive Verbindung weiterhin Daten. Wenn du länger als eine Minute gar nichts empfängst — weder eine Benachrichtigung noch einen Ping — gehe davon aus, dass die Verbindung unterbrochen ist. Stelle sie wieder her, statt darauf zu warten, dass der Socket dich informiert.
Wenig aktive Filter und das Inaktivitäts-timeout
Wenn dein Filter so eng gefasst ist, dass er berechtigterweise 10 Minuten lang keine Übereinstimmung findet, musst du damit rechnen, dass der Server die Verbindung mit Code 1000 schließt. Behandle dies wie jede andere geschlossene Verbindung: Stelle die Verbindung wieder her, abonniere erneut und führe wie unten beschrieben einen backfill für die Lücke durch.Verbindung wiederherstellen und Lücke erkennen
1
Reconnect with Backoff
Stelle die Verbindung nach jeder Trennung – ob erwartet oder nicht – mit exponentiellem Backoff wieder her. Abonnement-IDs bleiben bei einer erneuten Verbindung nicht erhalten. Sende daher
parsedTransactionSubscribe für jeden zuvor aktiven Filter erneut.2
Track context.slot Across Disconnects
Speichere den letzten
context.slot, den du vor der Trennung erhalten hast. Die Lücke zwischen diesem slot und dem ersten slot nach der erneuten Verbindung entspricht genau dem verpassten Fenster – nicht mehr und nicht weniger.3
Backfill if You Need To
Wenn deine Anwendung die Lücke nicht tolerieren kann, führe für dieses slot-Fenster einen backfill über RPC durch: Verwende
getSignaturesForAddress, um die Transaktionen im Bereich aufzulisten, und rufe dann jede einzelne mit getTransaction ab. Dies ist ein manueller Abgleichschritt – Parsed Streams selbst führt keine Wiederholung durch.context.slot bleibt nach einer erneuten Verbindung erhalten: Verfolge den höchsten slot, den du vor der Trennung vollständig verarbeitet hast, und behandle alles danach als backfill-Fenster.
JSON-RPC-Fehler behandeln
Fehlgeschlagene requests geben statt eines Ergebnisses einen JSON-RPC-Fehler zurück. Du kannst daher anhand vonerror.code verzweigen:
-32602 und -32000 bedeuten, dass der request selbst fehlerhaft ist. Korrigiere den Filter und wiederhole ihn nicht unverändert. -32001 und -32002 sind vorübergehend. Wiederhole den request mit demselben Backoff, den du für erneute Verbindungen verwendest.
Nächste Schritte
Quickstart
Vollständige Protokollreferenz: Methoden, Filterfelder und Limits.
Track Jupiter Swaps
Erstelle einen Filter, den diese Verbindung abonnieren kann.