Support Board
Date/Time: Sun, 18 Oct 2026 12:04:40 +0000
Post From: ACSIL Study for Automated Trading kicked off more than safeguard allowed
| [2026-09-03 20:56:32] |
| User158823 - Posts: 40 |
|
Thank you — the study has been cleared and its submissions are hard-coded market orders, which the Trade Activity Log confirms: every entry in the burst was a Limit order, which this study cannot submit. The burst instead consisted of limit parents tagged '1 ES with Auto BE+3Trg5.twconfig'; the IsAutomated column is blank for all of them (i.e., none are flagged as submitted by an automated trading system). The Trade Activity Log confirms the surviving orders were 12 separate 1-lot parents — not one 12-lot: Internal IDs 590, 593, 596, 599, 602 at 7679.00 (filled 15:46:09), then 1298–1316 at 7678.75 (filled 15:46:15), each parent carrying attached stop/target legs. The exit was a single 12-lot market order (Internal ID 1370) at 15:46:31. Two additional observations that may help locate the mechanism: 1. The rejected submission storm (Internal IDs 605–1369) repeated at a metronomic ~250ms cadence for ~9 seconds — parent rejected with 'Message rate limit reached,' then its two attached orders rejected with 'There is no parent order for child OCO order' — repeating in clusters of three. This signature suggests an automated retry loop, not manual input. No input automation was active during the window. 2. Normally, Buy/Sell Triggered Limit orders and plain limit orders display red or green once placed; orange appears only during the trigger-leg setup phase, before an order is confirmed. Yet these orders displayed as ORANGE badges on the DOM (at 7678.75 and 7679.00) while resting and while filling. This suggests the Trade Window treated them as orders stuck in an incomplete trigger-setup state. I therefore suspect the resubmission loop originates from the Trade Window's Triggered Limit / attached-order (Auto-BE) path retrying an order whose setup never reached a confirmed state after a 'Message rate limit reached' rejection. Questions: 1. What Sierra Chart mechanism resubmits a rejected Trade Window parent + its attached OCO children on a ~250ms timer? 2. Is there a setting or fix in the Trade Window attached-order / Auto-BE handling to prevent bracket-resubmission loops after a 'Message rate limit reached' rejection — and if it's a fix, which build includes it? Attached: Trade Service Log, Trade Activity Log>Trades and Trade Activity Log>TradeActivity for 02-SEP-2026. Thoughts? I just want to understand what may have triggered for this unexpected, unweldcomed event. Thank you so much for your patience and efforts. Kind regards, Gary Francis Mohamad |
 TradeServiceLog_2026-09-02_burst_SANITIZED.txt - Attached On 2026-09-03 20:55:28 UTC - Size: 156.77 KB - 33 views TradesTab_ESU26_2026-09-02_pnl_SANITIZED.txt - Attached On 2026-09-03 20:55:45 UTC - Size: 3.54 KB - 31 views TradeActivityLog_ESU26_2026-09-02_fills_SANITIZED.txt - Attached On 2026-09-03 20:55:58 UTC - Size: 5.58 KB - 37 views |