Zum Hauptinhalt springen
Die Zustellung erfolgt höchstens einmal — es gibt keine Wiederholung. Alles, was während des Verbindungsabbruchs bestätigt wurde, wird nicht erneut gesendet. Ein Produktionsclient muss daher die Lücke erkennen und entscheiden, ob er dafür einen Backfill ausführt. Das Signal dafür ist 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 von error.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.