Diagnóstico de conexión: «A market data session is already running. Disconnect it first»
El diagnóstico de conexión de Senzoukria abre su propia sesión de Rithmic, así que se niega a ejecutarse mientras haya una sesión de datos de mercado viva en el mismo login. También informa de lo que hizo el servidor durante la prueba, como un cierre de sesión forzado o una profundidad orden por orden rechazada.
Senzoukria · Solución de problemas · Actualizado en septiembre de 2026
En resumen
- Rechazo
- «A market data session is already running. Disconnect it first…»
- Aviso de cierre forzado
- «the server closed this session (forced logout) — typically a second session opened on the same login»
- Aviso de MBO
- «order-by-order depth (MBO) refused for {symbol} (rp_code=…); aggregated L2 depth still works»
- No incluido
- Ninguna descarga de historial: el diagnóstico no prueba el history plant
Qué ves
Pulsar «Ejecutar el diagnóstico» mientras un gráfico está recibiendo datos devuelve: «A market data session is already running. Disconnect it first: this diagnostic opens its own session, and Rithmic refuses — or silently kills — a second session on the same login. The refusal would look exactly like the entitlement wall this is meant to rule out.» Este texto lo redacta el motor y se muestra en inglés.
Cuando el diagnóstico sí se ejecuta, su resultado puede llevar avisos descodificados durante la sesión: «the server closed this session (forced logout) — typically a second session opened on the same login», o «order-by-order depth (MBO) refused for {symbol} (rp_code=…); aggregated L2 depth still works».
Por qué ocurre
El diagnóstico recorre la pasarela, el sistema, el login, la suscripción y el primer tick con una sesión propia. Ejecutado al lado de un flujo en vivo, podría romper ese flujo, o ser rechazado y hacer que un simple límite de sesiones parezca una falta de permisos, que es justamente el diagnóstico falso que existe para evitar. Así que se detiene antes de abrir nada.
Un cierre de sesión forzado durante la prueba es una causa conocida de silencio: el paso del primer tick falla, el aviso lo nombra, y la aplicación no muestra el bloque «Todo fue aceptado, no llega ningún dato». Un rechazo de MBO solo afecta a la profundidad orden por orden; la L2 agregada sigue funcionando. El diagnóstico no descarga historial a propósito, porque pedir historial en exceso es el principal sospechoso de los rechazos intermitentes con rp_code 13.
Cómo solucionarlo
- Desconecta la conexión en vivo desde su tarjeta en Conexiones de broker y vuelve a ejecutar el diagnóstico.
- Cierra R | Trader Pro o cualquier otra plataforma conectada con el mismo login antes de probar.
- Si el resultado muestra un cierre de sesión forzado, busca la otra sesión de ese login y ciérrala.
- Después de la prueba, vuelve a conectar tu perfil; el diagnóstico desmonta su propia sesión.
Lo que no es
- No es un fallo de tu conexión: el diagnóstico se ha negado a arrancar.
- No es una prueba del historial: los rechazos de historial se muestran en el gráfico con sus propios avisos.
Cuándo contactar con soporte
¿Sigues bloqueado después de estas comprobaciones? Usa Menú → Informar de un problema, o escribe en el Discord de Senzoukria. Usa «Copiar el resultado» tras una ejecución completa; incluye los avisos y ninguna contraseña.
Páginas relacionadas
En la misma sección
- Bridge Quantower no conecta
- Botones de orden desactivados
- El demo gratuito de Rithmic no conecta
- Big Trades no aparece
- GEX con retraso o desactualizado
- Ya hay una carga en curso
- GEX sin datos o error del proveedor
- Trading desactivado en la conexión
Esta página en otros idiomas
Preguntas frecuentes
- ¿Por qué el diagnóstico no puede compartir mi sesión en vivo?
- Porque mide cada paso él mismo, desde la pasarela hasta el primer tick. Reutilizar una sesión en curso se saltaría los pasos que pretende probar.
- ¿Un rechazo de MBO significa que mi DOM está roto?
- No. Significa que la profundidad orden por orden fue rechazada para ese contrato; la profundidad L2 agregada sigue funcionando.