Skip to main content
La entrega se realiza como máximo una vez; no hay reproducción. Lo que se haya confirmado mientras estabas desconectado no se vuelve a enviar, por lo que un cliente de producción debe detectar la interrupción y decidir si necesita recuperar los datos faltantes. La señal para hacerlo es context.slot: delimita la ventana que perdiste durante una desconexión. Esta guía explica por qué se cierran las conexiones, cómo volver a conectarte correctamente y cómo usar esta señal.

Por qué se cierran las conexiones

Cada cierre tiene un código de cierre de WebSocket que indica qué ocurrió y qué hacer a continuación: El servidor envía un ping cada 15 segundos, por lo que incluso una conexión activa pero sin actividad sigue transportando tráfico. Si no recibes absolutamente nada durante más de un minuto —ni notificaciones ni pings—, asume que la conexión está inactiva y vuelve a conectarte en lugar de esperar a que el socket te lo indique.

Mantén activa la conexión

Si tu filtro es tan específico que puede pasar legítimamente 10 minutos sin encontrar coincidencias, envía explícitamente un ping de JSON-RPC en un intervalo menor:
Devuelve el slot actual y, lo que es más importante, cuenta como un mensaje del cliente para el temporizador de inactividad. Una trama ping de WebSocket a nivel de biblioteca no cuenta.

Vuelve a conectarte y detecta la interrupción

1

Reconnect with Backoff

Ante cualquier cierre, esperado o no, vuelve a conectarte con espera exponencial. Los identificadores de suscripción no se conservan después de una reconexión, así que vuelve a enviar parsedTransactionSubscribe para cada filtro que tenías abierto.
2

Track context.slot Across Disconnects

Conserva el último context.slot que recibiste antes de la desconexión. La diferencia entre ese slot y el primer slot que recibas después de volver a conectarte es exactamente la ventana que perdiste, ni más ni menos.
3

Backfill if You Need To

Si tu aplicación no puede tolerar la interrupción, recupera los datos de esa ventana de slots mediante RPC: usa getSignaturesForAddress para enumerar las transacciones del intervalo y luego getTransaction para obtener cada una. Este es un paso de conciliación manual; Parsed Streams no reproduce los datos.
context.slot es lo que se conserva tras una reconexión: registra el slot más alto que hayas procesado por completo antes de la desconexión y considera todo lo posterior como la ventana de recuperación.

Gestión de errores de JSON-RPC

Las solicitudes que fallan devuelven un error de JSON-RPC en lugar de un resultado, por lo que puedes bifurcar la lógica según error.code: -32602 e -32000 indican que la solicitud es incorrecta: corrige el filtro y no vuelvas a intentarlo sin cambios. -32001 e -32002 son errores transitorios; vuelve a intentarlo con la misma espera exponencial que usas para las reconexiones.

Próximos pasos

Quickstart

Referencia completa del protocolo: métodos, campos de filtro y límites.

Track Jupiter Swaps

Crea un filtro al que esta conexión pueda suscribirse.