Support Board
Date/Time: Wed, 24 Jun 2026 20:00:43 +0000
Post From: Attached order (take-profit) cancel/replace rejected during partial parent fill
| [2026-06-24 17:28:49] |
| PapaHertz - Posts: 5 |
|
I trade a bracket (Stop-Limit parent entry with attached Target and Stop) on NQU6.CME via Rithmic Direct. On fast entries that partially fill, the take-profit's quantity-increase modification is being rejected, and the result is that part of my position is left without a working profit target at the moment price reaches it. Two examples from my Trade Activity Log on 2026-06-24 (account LFE050-377U6HPS-TEST004): Internal Order 2479 (parent), ~15:47:07 UTC: parent partial-filled (1 then 2), TP child 2480 was sent at qty 1 and filled 1 at target, then the increase-to-3 modification on 2480 produced "Order modification failed — Order cancel/replace reject" at 15:47:07.969. Remaining contracts had no working TP and were stopped out. Internal Order 2482 (parent), ~16:41:43 UTC: parent partial-filled (1/1/2), the increase modifications on children 2483/2484 stacked ("Removed 1 prior delayed modification due to later modification… increasing 1 to 4"), then cancel/replace rejects, then at 16:44 "Order cancellation failed — timed-out waiting for cancel response." My questions: Is this the expected behavior when a parent fills in multiple parts faster than the attached-order quantity modifications can complete — i.e., the resize cancel/replace colliding with the child's own fill? "Reactivate Attached Order when Rejected Modification During Fill" is already set to Yes. It's firing in the log ("Reactivating order when performing delayed modification") but isn't preventing the exposure. Is there an additional setting or a configuration that more reliably handles partial-fill bracket resizing? Is there any way to have the attached orders submitted at full intended quantity rather than being resized incrementally as the parent partial-fills? Or is incremental resizing inherent to the feature? Would server-side bracket orders (Use Server Side Bracket Orders) change this behavior for Rithmic, or is Rithmic's OCO/bracket handling client-side here? Is there anything specific about Rithmic's cancel/replace handling during fills that makes this worse, versus other trading services? I have provided the full Trade Activity Log export and Trade Service Log for that session. |
 TradeActivityLogExport_2026-06-24.txt - Attached On 2026-06-24 17:23:52 UTC - Size: 161.94 KB - 2 views 2026-06-24 _Trade_Service_Log_Rithmic Di.txt - Attached On 2026-06-24 17:26:05 UTC - Size: 6.48 KB - 2 views |