Expected Behavior
Algorithms should be able to programmatically trigger a brokerage reconnect when they detect data-quality anomalies (e.g. consecutive zero-volume bars during market hours while the connection is technically alive). A method such as self.reconnect_brokerage() on QCAlgorithm would allow the algorithm to recover without human intervention or process restart.
Actual Behavior
There is no way for an algorithm to trigger a brokerage Disconnect/Connect cycle. QCAlgorithm holds an internal IBrokerage reference but does not expose it. The only workarounds are:
self.Quit() — exits the algorithm entirely, disrupting live positions- Out-of-process IPC (flag files, sockets) between the algorithm thread and the brokerage heartbeat thread — fragile and non-portable
This gap is particularly visible with IBKR, where the gateway can enter a state where heartbeats succeed but the market data feed silently freezes (bars arrive with Volume = 0). The algorithm layer can detect this condition but has no recourse.
Potential Solution
Add a single public method to QCAlgorithm:
public void ReconnectBrokerage()
{
try { Brokerage.Disconnect(); } catch (Exception) { }
Brokerage.Connect();
}Python usage:
def on_consolidated_bar(self, bar):
if self._is_data_frozen(bar):
self.log("Data feed frozen, triggering reconnect")
self.reconnect_brokerage()The change is brokerage-agnostic and minimal — QCAlgorithm already holds the IBrokerage reference internally.
Open design questions we'd welcome feedback on before submitting a PR:
Should there be a built-in cooldown guard, or leave rate-limiting to the algorithm author?
Should the method emit a BrokerageMessageEvent before reconnecting so the live trading monitor is aware?
We are happy to contribute a PR if the team agrees on the API shape.
Checklist
Expected Behavior
Algorithms should be able to programmatically trigger a brokerage reconnect when they detect data-quality anomalies (e.g. consecutive zero-volume bars during market hours while the connection is technically alive). A method such as
self.reconnect_brokerage()onQCAlgorithmwould allow the algorithm to recover without human intervention or process restart.Actual Behavior
There is no way for an algorithm to trigger a brokerage
Disconnect/Connectcycle.QCAlgorithmholds an internalIBrokeragereference but does not expose it. The only workarounds are:self.Quit()— exits the algorithm entirely, disrupting live positionsThis gap is particularly visible with IBKR, where the gateway can enter a state where heartbeats succeed but the market data feed silently freezes (bars arrive with
Volume = 0). The algorithm layer can detect this condition but has no recourse.Potential Solution
Add a single public method to
QCAlgorithm:Python usage:
The change is brokerage-agnostic and minimal — QCAlgorithm already holds the IBrokerage reference internally.
Open design questions we'd welcome feedback on before submitting a PR:
Should there be a built-in cooldown guard, or leave rate-limiting to the algorithm author?
Should the method emit a BrokerageMessageEvent before reconnecting so the live trading monitor is aware?
We are happy to contribute a PR if the team agrees on the API shape.
Checklist