Tras reconectar un WebSocket con proxy, restaura también la sesión
Restaura deliberadamente las suscripciones de la aplicación y el estado incierto de los mensajes después de establecer una nueva conexión WebSocket con proxy.
Se ejecuta la devolución de llamada de reconexión y el nuevo socket se abre. Eso es recuperación del transporte. No significa necesariamente que tus suscripciones, acuses de recibo de mensajes o la sesión de la aplicación continuaran donde se detuvo la conexión anterior.
Incluso el mismo extremo de proxy puede producir una nueva conexión saliente. Una IP de salida cambiada también puede activar la política de sesión propia del destino. Trata el nuevo socket como una conexión nueva y sigue el intercambio de recuperación documentado de la aplicación. Decide si el flujo de trabajo debe conservar su ruta de proxy al reconectar.
Conserva algo más que la última URL
El estado de recuperación útil puede incluir una identidad de sesión autorizada, las suscripciones deseadas, el identificador del último evento confirmado y las operaciones que aún esperan confirmación. Esos campos pertenecen al protocolo de la aplicación; WebSocket no define un token de reanudación universal.
Decide si reanudar desde un cursor, obtener una instantánea nueva o aceptar un hueco. Si una fuente de eventos no ofrece interfaz de reproducción, reconectar más rápido no puede demostrar que no se hayan perdido mensajes.
Enviar dos veces puede significar hacerlo dos veces
Un mensaje encolado localmente antes de una desconexión puede que nunca saliera del cliente. Otro puede haber llegado al servidor mientras se perdía su acuse. Reenviar a ciegas cada comando sin confirmar trata esos dos casos como idénticos.
Usa los identificadores de solicitud del servicio, la compatibilidad con idempotencia o el mecanismo de conciliación cuando estén disponibles. Una reconexión del transporte no puede hacer reversible una acción de la aplicación ni deduplicarla automáticamente.
Mantén los intentos de reconexión acotados y con un ritmo acorde a la política de la aplicación. La RFC 6455 recomienda retroceder tras un cierre anormal; una flota de clientes que reintentan de inmediato puede aumentar la carga de la interrupción.
Registra qué ruta de proxy eligió cada intento, pero mantén la recuperación de la ruta separada de la recuperación de la aplicación. «Conectados de nuevo» es una evidencia útil. «Al día y listos para enviar más trabajo» necesita el intercambio adicional de la aplicación que lo establece.