Connection diagnostic: “A market data session is already running. Disconnect it first”

The Senzoukria connection diagnostic opens its own Rithmic session, so it refuses to run while a market data session is live on the same login. It also reports what the server did during the test, such as a forced logout or a refused order-by-order depth.

Senzoukria · Troubleshooting · Updated September 2026

At a glance

Refusal
“A market data session is already running. Disconnect it first…”
Forced logout alert
“the server closed this session (forced logout) — typically a second session opened on the same login”
MBO alert
“order-by-order depth (MBO) refused for {symbol} (rp_code=…); aggregated L2 depth still works”
Not included
No history download: the diagnostic does not test the history plant

What you see

Clicking “Run the diagnostic” while a chart is streaming returns: “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.”

When the diagnostic does run, its result can carry alerts decoded during the session: “the server closed this session (forced logout) — typically a second session opened on the same login”, or “order-by-order depth (MBO) refused for {symbol} (rp_code=…); aggregated L2 depth still works”.

Why it happens

The diagnostic walks gateway, system, login, subscription and first tick with a session of its own. Run next to a live feed, it could break that feed, or be refused and make an ordinary session limit look like missing permissions, which is the false diagnosis it exists to prevent. So it stops before opening anything.

A forced logout during the test is a known cause of silence: the first-tick step fails, the alert names it, and the app does not show the “Everything was accepted, no data is arriving” block. An MBO refusal only concerns order-by-order depth; aggregated L2 keeps working. The diagnostic deliberately does not download history, because over-fetching history is the leading suspect for intermittent rp_code 13 refusals.

How to fix it

  • Disconnect the live connection from its card in Broker Connections, then run the diagnostic again.
  • Close R | Trader Pro or any other platform signed in with the same login before testing.
  • If the result shows a forced logout, find the other session on that login and close it.
  • After the test, reconnect your profile; the diagnostic tears its own session down.

What it is not

  • Not a failure of your connection: the diagnostic refused to start.
  • Not a history test: history refusals show on the chart with their own notices.

When to contact support

Still stuck after these checks? Use Menu → Report a problem, or post on the Senzoukria Discord. Use “Copy the result” after a completed run; it includes the alerts and no password.

In the same section

This page in other languages

Frequently asked questions

Why can’t the diagnostic share my live session?
It measures each step itself, from the gateway to the first tick. Reusing a running session would skip the steps it is meant to test.
Does an MBO refusal mean my DOM is broken?
No. It means order-by-order depth was refused for that contract; aggregated L2 depth still works.

Keep reading

Strategy researchTest a trading strategy, from observation to challenge rulesDefine an observation, question it with the copilot, write a rule and explore costs, drawdown and fictional challenge limits in an interactive example.Quant · Start hereQuant trading for beginners: from idea to backtestDefine a testable rule, choose suitable data and evaluate later periods after costs.Order flow · HubOrder flow trading: the complete guideThe hub. What order flow is, what it shows — aggression, delta, imbalance, absorption, liquidity — and the tools that read it, each linked to a full guide.