Hi everyone,

I'm running two live algorithms on Charles Schwab through QuantConnect (two separate accounts under the same Schwab login). Both algorithms rely on E10-stable HLK architecture with IM-3.1 indicator sync, ObjectStore persistence, and full reconciliation.

Over the past 48 hours, I’ve encountered two independent issues that appear related to the Schwab integration layer, token lifecycle, and WebSocket event handling. I'm hoping the community or QC Engineers can clarify expected behavior and whether this reflects current limitations or correctable defects.

1️⃣ Missing Order Event: Fill at Schwab, but QC reports “No response received”

One live job (BobFun648) attempted a market exit in GOOGL.
The order filled successfully at Schwab, but Lean logged:

 

Runtime Error: No response received for order by BrokerageId = XXXXX and Lean Order = 3 (New Market order for -69 GOOGL)

This happened mid-session, not during token renewal.

Lean never received a fill or status event, causing:

An exception

A forced shutdown of the algorithm

Auto-restart did not trigger

Upon restart, QC performed the usual open-order reconstruction and ObjectStore recovery.

Questions:

Under what conditions can Schwab execute an order but Lean receives no WebSocket event?

Is there a fallback REST "order status check" planned to handle this failure mode?

Does the Schwab integration guarantee at-least-once event delivery after reconnect?

2️⃣ Second algorithm terminated due to token expiration after hours

My second job (BobIRA346) later failed during extended hours with:

 

Service=Admin, Command=Login Content: Code=3, Message=Login Denied: token is invalid or expired.

Even though:

This same token was renewed 3 days ago

That algorithm had been running without interruption

Live trading for the day was already complete

Questions:

Why does a token renewal event cause a fatal runtime error instead of triggering auto-restart?

Does the Schwab WebSocket require a completely separate token renewal workflow from REST?

Is QuantConnect able to implement a more graceful reconnect path for Code=3 conditions?

3️⃣ Multi-Account Clarification: QC says “not supported,” Schwab says “supported”

I received two conflicting statements:

From QuantConnect Support:

“The QuantConnect–Charles Schwab integration no longer supports multiple accounts. Deploying a second algorithm will stop the first one.”

From Schwab Trader API Support (direct email):

“The Schwab API still allows you to authenticate multiple accounts at the same time.
If you’re seeing an error, please provide screenshots.”

These positions are incompatible.

Questions:

Does QC enforce a single live Schwab session per user, even if Schwab allows multiple accounts?

If so, is this a temporary safety measure or a structural limitation of the current integration?

Should users expect one Schwab-based live algorithm maximum per QC organization?

4️⃣ Suggested Engineering Improvements

If helpful to QC staff, here are potential ways to increase reliability:

Add REST-based status reconciliation when filling orders (fallback for missing events)

Soft-restart upon Code=3 instead of fatal termination

Expose token age/status in logs for proactive renewal

Document concurrency/session limitations explicitly

5️⃣ Logs Available

I have complete logs for:

The GOOGL order failure

The post-midnight token-expiration crash

ObjectStore reconstruction

WebSocket admin messages

Restart behavior

Happy to provide them directly if needed.

Closing

I’m not reporting these as complaints — HLK has been rock solid, and I appreciate all the work behind the Schwab integration. I’m just trying to understand:

What behavior is expected

What is currently unsupported

What failure modes I should design around

Thanks in advance to QC engineers and the community for any clarification or guidance.

— Bob