Saltar al contenido principal
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.

Filtros con poca actividad y el tiempo de espera por inactividad

Si tu filtro es tan específico que legítimamente puede pasar 10 minutos sin encontrar una coincidencia, espera que el servidor cierre la conexión con el código 1000. Trátalo como cualquier otro cierre: vuelve a conectarte, vuelve a suscribirte y recupera los datos faltantes como se describe a continuación.

Volver a conectarte y detectar el intervalo faltante

1

Reconnect with Backoff

Ante cualquier cierre, previsto o no, vuelve a conectarte con un retraso exponencial. Los IDs de suscripción no se conservan al volver a conectarte, así que reenvía parsedTransactionSubscribe por cada filtro que tenías abierto.
2

Track context.slot Across Disconnects

Conserva el último context.slot que viste antes de la desconexión. El intervalo entre ese slot y el primero que veas después de volver a conectarte es exactamente el que perdiste, ni más ni menos.
3

Backfill if You Need To

Si tu aplicación no puede tolerar ese intervalo, 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 al volver a conectarte: registra el slot más alto que procesaste por completo antes de la desconexión y considera todo lo posterior como la ventana de recuperación de datos.

Manejar 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 propia solicitud es incorrecta: corrige el filtro, no vuelvas a intentarlo sin cambios. -32001 e -32002 son errores transitorios; vuelve a intentarlo con el mismo retraso 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.