|
Has anyone ever experienced the following error when trying to modify bracket orders ?
10326 - OCA group revision is not allowed
It is not documented in the API documentation and IB requires detailed TWS logging in order to provide assistance.
--
|
you ever figure out if this is possible?
|
I believe this is a bug that occurs in TWS 10.30+
I see this message when trying to modify the limit or stop price of an OCA order in TWS 10.30+; same code works fine in TWS 10.19.
TWS log shows that there is no OCA group revision.
There is also a related error ("OCA handling method mismatch") which (I think) occurs when submitting dependent OCA orders (again, only TWS 10.30+)
OCA orders are really messed up in 10.30+, and I have an IB ticket that TWS API support is investigating (ticket #804191, if you would like to contribute).
|
I would like to confirm that IBKR has some serious problems with software releases. 10.30.1o released Oct 24 is garbage. I tried to create a simple bracket order (through API) and once the parent order was filled I tried to modify the stop order and later the target order. Both attempts failed with error 135: parent order not found. I created a ticket. Two days later IBKR released 10.30,1p with the same results. I downloaded 10.23, which works and sent logs from both 10.30.1p and 10.23 repeating the same bracket order test . I was advised not to use 10.30.1p. On Nov 12 10.30.1q was released. I managed to to modify stop order in the bracket order once. Any other attempt after that failed with the same error.. It shows how little care and virtually no testing takes place at IBKR (bracket order is so basic one) . How long they are going to be in business !?
One lesson to be learned: keep the working version in a separate directory, test new software release in paper account before using it in your live account.Here is the link to 10.23 which is not going to be overwritten by automatic software update.
?
?
?
[Moderator Addition]
Please not that TWS 10,23 is available for download only not IBKR.
|
After upgrading, the api and tws I ran into similar problems, but
they all are fixable. Here's my original post:
/g/twsapi/topic/java_tws_api_972_03_too_old/109159281
In the old situation, I always updated an oca child order with the
same parameters, including the parentId . That no longers works. And
the error message is actually helpful ;-) Leave parentId out when
updating a child oca order when the parent has already been
triggered. Worked for me.
Good luck, regards,
Raoul
On 13-11-2024 17:19, Andrew Flis via
groups.io wrote:
toggle quoted message
Show quoted text
I would like to confirm that IBKR has some
serious problems with software releases. 10.30.1o released Oct
24 is garbage. I tried to create a simple bracket order
(through API) and once the parent order was filled I tried to
modify the stop order and later the target order. Both
attempts failed with error 135: parent order not found. I
created a ticket. Two days later IBKR released 10.30,1p with
the same results. I downloaded 10.23, which works and sent
logs from both 10.30.1p and 10.23 repeating the same bracket
order test . I was advised not to use 10.30.1p. On Nov 12
10.30.1q was released. I managed to to modify stop order in
the bracket order once. Any other attempt after that failed
with the same error.. It shows how little care and virtually
no testing takes place at IBKR (bracket order is
so basic one) . How long they are going to be in business !?
One lesson to be learned: keep the working
version in a separate directory, test new software release in
paper account before using it in your live account.Here
is the link to 10.23 which is not going to be overwritten by
automatic software update.
?
?
?
[Moderator Addition]
Please not that TWS 10,23 is available for
download only not IBKR.
|
Revisiting this as the deadline to upgrade to 10.30.1t looms.
?
Raoul, my OCA orders' parent id is 0 already, so unfortunately I think the issue I'm encountering is different than what your post suggests.
?
The first time I run 10.30.1t and submit (via the API) OCA orders, a dialog comes up that says:
?
Overfill Protection Precaution
Invalid parameter for OCA group for exchange SMART. Overfill protection is implied.
Do you want to apply the correct parameter?
?
I choose yes and check "Don't display this message again".
?
Afterwards, the OCA orders get submitted, but they get rejected with "OCA handling method mismatch".
?
I brought this up with IB in October, yet the issue persists in "stable" version 10.30.1t.
?
Has anyone here figured out a solution to this "OCA handling method mismatch"?
My previous tests showed this was working in 10.32, but I will try this again tomorrow to confirm (likely in the latest offline version 10.34.1a, since 10.32 is not available anymore).
?
Thanks!
|
You can permanently enable/disable various order precautions in the global settings of TWS and IBGW under API --> Precautions.
When you call placeOrder() to modify the OCA order, what kind of Order object do you use?
- The object you used when you placed the original bracket order (with modified stop price and possibly other fields) ?
- Or the Order objects you received in the most recent openOrder() callback?
Also, do you modify OCA order before or after the parent order has been filled?
´³¨¹°ù²µ±ð²Ô
?
?
On Mon, Feb 10, 2025 at 07:08 PM, Jimmy wrote:
Revisiting this as the deadline to upgrade to 10.30.1t looms.
?
Raoul, my OCA orders' parent id is 0 already, so unfortunately I think the issue I'm encountering is different than what your post suggests.
?
The first time I run 10.30.1t and submit (via the API) OCA orders, a dialog comes up that says:
?
Overfill Protection Precaution
Invalid parameter for OCA group for exchange SMART. Overfill protection is implied.
Do you want to apply the correct parameter?
?
I choose yes and check "Don't display this message again".
?
Afterwards, the OCA orders get submitted, but they get rejected with "OCA handling method mismatch".
?
I brought this up with IB in October, yet the issue persists in "stable" version 10.30.1t.
?
Has anyone here figured out a solution to this "OCA handling method mismatch"?
My previous tests showed this was working in 10.32, but I will try this again tomorrow to confirm (likely in the latest offline version 10.34.1a, since 10.32 is not available anymore).
?
Thanks!
|
Thanks for the reply ´³¨¹°ù²µ±ð²Ô.
?
At this time, I'm not modifying orders. I am just submitting two single-legged option OCA bracket orders, one with a stop price, one with a limit price.
?
I am testing using a paper trading account.
I unchecked the "bypass No Overfill Protection precaution for destinations where implied natively" checkbox in API -> precautions, but I can't get the dialog to come up again (I don't know if the behavior would be the same a live account).
?
I tested with both the current stable version (10.30.1t) and latest (10.34.1b); the results are the same
?
When submitting Option OCA orders with OcaType = 2 (which the precaution dialog implies is what is needed), they get rejected with "OCA handling method mismatch".
When using OcaType = 3, they get rejected with "Invalid parameter for OCA group for exchange SMART".
?
OcaType = 3 works fine in 10.19 and before (that's what I've always used). However, I tried OcaType = 2 with 10.19 in a live account yesterday, and I also got the same error message "Invalid parameter for OCA group for exchange SMART".
?
Is anyone else using OCA orders with options? Is it working for you in 10.30+? What OcaType are you using??
?
Thanks
Jimmy
|
Thanks for the clarification, Jimmy. I had responded to when you had said in an earlier reply "I see this message when trying to modify the limit or stop price of an OCA order"
What are you trying to achieve with the OCA order? Do you want one and only one of those two orders to fill? If that is the case, wouldn't OCA Type 1 "CancelWithBlocking" be the type you are looking for? Types 2 and 3 are "Reduce" types with and without blocking.
´³¨¹°ù²µ±ð²Ô
?
On Tue, Feb 11, 2025 at 11:18 AM, Jimmy wrote:
Thanks for the reply ´³¨¹°ù²µ±ð²Ô.
?
At this time, I'm not modifying orders. I am just submitting two single-legged option OCA bracket orders, one with a stop price, one with a limit price.
?
I am testing using a paper trading account.
I unchecked the "bypass No Overfill Protection precaution for destinations where implied natively" checkbox in API -> precautions, but I can't get the dialog to come up again (I don't know if the behavior would be the same a live account).
?
I tested with both the current stable version (10.30.1t) and latest (10.34.1b); the results are the same
?
When submitting Option OCA orders with OcaType = 2 (which the precaution dialog implies is what is needed), they get rejected with "OCA handling method mismatch".
When using OcaType = 3, they get rejected with "Invalid parameter for OCA group for exchange SMART".
?
OcaType = 3 works fine in 10.19 and before (that's what I've always used). However, I tried OcaType = 2 with 10.19 in a live account yesterday, and I also got the same error message "Invalid parameter for OCA group for exchange SMART".
?
Is anyone else using OCA orders with options? Is it working for you in 10.30+? What OcaType are you using??
?
Thanks
Jimmy
|
If one order gets 1 contract filled, I don't want the other orders in the OCA group to be cancelled immediately; I want the other orders to remain active, with 1 contract to get subtracted from their?quantity.? Only when an entire order in the?OCA group is filled do I want the other orders to be cancelled.? This is the "reduce" behavior I believe (at least it was until now). I could live with OcaType 2 or 3, but right now, as far as I can tell, neither works with TWS 10.30+.
On Tue, Feb 11, 2025 at 12:42?PM ´³¨¹°ù²µ±ð²Ô Reinold via <TwsApiOnGroupsIo= [email protected]> wrote:
Thanks for the clarification, Jimmy. I had responded to when you had said in an earlier reply "I see this message when trying to modify the limit or stop price of an OCA order"
What are you trying to achieve with the OCA order? Do you want one and only one of those two orders to fill? If that is the case, wouldn't OCA Type 1 "CancelWithBlocking" be the type you are looking for? Types 2 and 3 are "Reduce" types with and without blocking.
´³¨¹°ù²µ±ð²Ô
?
On Tue, Feb 11, 2025 at 11:18 AM, Jimmy wrote:
Thanks for the reply ´³¨¹°ù²µ±ð²Ô.
?
At this time, I'm not modifying orders. I am just submitting two single-legged option OCA bracket orders, one with a stop price, one with a limit price.
?
I am testing using a paper trading account.
I unchecked the "bypass No Overfill Protection precaution for destinations where implied natively" checkbox in API -> precautions, but I can't get the dialog to come up again (I don't know if the behavior would be the same a live account).
?
I tested with both the current stable version (10.30.1t) and latest (10.34.1b); the results are the same
?
When submitting Option OCA orders with OcaType = 2 (which the precaution dialog implies is what is needed), they get rejected with "OCA handling method mismatch".
When using OcaType = 3, they get rejected with "Invalid parameter for OCA group for exchange SMART".
?
OcaType = 3 works fine in 10.19 and before (that's what I've always used). However, I tried OcaType = 2 with 10.19 in a live account yesterday, and I also got the same error message "Invalid parameter for OCA group for exchange SMART".
?
Is anyone else using OCA orders with options? Is it working for you in 10.30+? What OcaType are you using??
?
Thanks
Jimmy
|
Today,? OcaType 2 works with both 10.30 and 10.34, at least in a paper trading account.?I will try it in a live account with?version 10.30 this evening, and if it works, in a live account during the day tomorrow.
If one order gets 1 contract filled, I don't want the other orders in the OCA group to be cancelled immediately; I want the other orders to remain active, with 1 contract to get subtracted from their?quantity.? Only when an entire order in the?OCA group is filled do I want the other orders to be cancelled.? This is the "reduce" behavior I believe (at least it was until now). I could live with OcaType 2 or 3, but right now, as far as I can tell, neither works with TWS 10.30+.
On Tue, Feb 11, 2025 at 12:42?PM ´³¨¹°ù²µ±ð²Ô Reinold via <TwsApiOnGroupsIo= [email protected]> wrote: Thanks for the clarification, Jimmy. I had responded to when you had said in an earlier reply "I see this message when trying to modify the limit or stop price of an OCA order"
What are you trying to achieve with the OCA order? Do you want one and only one of those two orders to fill? If that is the case, wouldn't OCA Type 1 "CancelWithBlocking" be the type you are looking for? Types 2 and 3 are "Reduce" types with and without blocking.
´³¨¹°ù²µ±ð²Ô
?
On Tue, Feb 11, 2025 at 11:18 AM, Jimmy wrote:
Thanks for the reply ´³¨¹°ù²µ±ð²Ô.
?
At this time, I'm not modifying orders. I am just submitting two single-legged option OCA bracket orders, one with a stop price, one with a limit price.
?
I am testing using a paper trading account.
I unchecked the "bypass No Overfill Protection precaution for destinations where implied natively" checkbox in API -> precautions, but I can't get the dialog to come up again (I don't know if the behavior would be the same a live account).
?
I tested with both the current stable version (10.30.1t) and latest (10.34.1b); the results are the same
?
When submitting Option OCA orders with OcaType = 2 (which the precaution dialog implies is what is needed), they get rejected with "OCA handling method mismatch".
When using OcaType = 3, they get rejected with "Invalid parameter for OCA group for exchange SMART".
?
OcaType = 3 works fine in 10.19 and before (that's what I've always used). However, I tried OcaType = 2 with 10.19 in a live account yesterday, and I also got the same error message "Invalid parameter for OCA group for exchange SMART".
?
Is anyone else using OCA orders with options? Is it working for you in 10.30+? What OcaType are you using??
?
Thanks
Jimmy
|
This appeared as I migrated from 10.23 to 10.34 (tested with 10.30, same thing). Previously it worked fine.
I have read all previous posts related to this error. I made sure parentId=0, but it made no difference. I turned off all precautions and warnings. No love. Other points discussed did not seem immediately relevant to my situation.
The error code does not appear in any IB documentation I have been able to find.
?
What I do is very simple. For ES or NQ (mini futs) I enter a bracket, let's say to buy (LMT) with 2 OCA children, one profit-taking sell (LMT), the other sell STP.
I get filled and all looks good, two open orders appear. Let's call this state of affairs 1. If either gets filled, the other disappears as one would wish. So far so good. We can call this state 2.
But ... the problem occurs if in state 1, with the 2 OCA children still open, I decide to change the price in the profit-taking LMT.
That's when I get?
10326 OCA group revision is not allowed
The request is ignored, and the 2 OCA orders stay open unaltered.
?
This probably doesn't matter much, but my rationale for changing the price is to trigger the sell and close the position with minimal hassle, because my model views further waiting under the circumstances as unlikely to bear fruit. I suppose I could cancel and exit via MKT sell, but this seems simpler, more graceful, it used to work fine, and I miss those days.
?
I use ocaType=2, in case this is relevant.
?
Any help would be greatly appreciated.
?
?
|
Works just fine for me on TWS 10.30.1u, TWS API level 173, and ESH5. Both for the IBKR default OCA type 3 as well as type 2 as you use.
What API level does your client use?
My approach is rather simple:
- I get a properly initialized Contract object for ESH5 from IBKR via reqContractDetails().
- I construct a regular bracket order with a LMT BUY entry (parent order), LMT profit taker, and STP stop loss order, and place it with the Contract object received from IBKR. The Entry order is priced at the current ask price and fills pretty much immediately. The profit and loss orders are priced 100 ticks away from the entry price (just that they do not trigger right away).
- My OrderController/TradeManager listens for openOrder() callbacks and maintains the most recent Entry, Profit, and Loss Order states and objects received from IBKR.
- 60 seconds after the entry order fills, the profit taker price is moved10 ticks closer to the entry price. This is done by changing the limit price of the most recent Profit Order object received from IBKR at that point.
Hope this helps.
´³¨¹°ù²µ±ð²Ô
?
The original bracket order:
[ {
? "orderId" : 2,
? "parentId" : 0,
? "action" : "BUY",
? "totalQuantity" : 1,
? "orderType" : "LMT",
? "lmtPrice" : 5618.75,
? "tif" : "GTC",
? "orderRef" : "Entry",
? "ocaType" : 0
}, {
? "orderId" : 3,
? "parentId" : 2,
? "action" : "SELL",
? "totalQuantity" : 1,
? "orderType" : "LMT",
? "lmtPrice" : 5643.75,
? "tif" : "GTC",
? "orderRef" : "PTaker",
? "ocaType" : 2
}, {
? "orderId" : 4,
? "parentId" : 2,
? "action" : "SELL",
? "totalQuantity" : 1,
? "orderType" : "STP",
? "auxPrice" : 5593.75,
? "tif" : "GTC",
? "orderRef" : "SLoss",
? "ocaType" : 2
} ]
?
The three orders in TWS:
?
The Profit Taker order as updated by and received from IBKR:
{
? "clientId" : 1741825477,
? "orderId" : 3,
? "permId" : 2088634287,
? "parentId" : 2,
? "action" : "SELL",
? "totalQuantity" : 1,
? "orderType" : "LMT",
? "lmtPrice" : 5643.75,
? "tif" : "GTC",
? "account" : "XXXXXXXX",
? "clearingIntent" : "IB",
? "ocaGroup" : "2088634286",
? "orderRef" : "PTaker",
? "ocaType" : 2,
? "transmit" : true
}
?
The only change to that order object:
?
{
? "lmtPrice" : 5641.25
}
?
?
The updated Profit Taker order in TWS:
?
?
On Wed, Mar 12, 2025 at 03:58 PM, Max Payne wrote:
This appeared as I migrated from 10.23 to 10.34 (tested with 10.30, same thing). Previously it worked fine.
I have read all previous posts related to this error. I made sure parentId=0, but it made no difference. I turned off all precautions and warnings. No love. Other points discussed did not seem immediately relevant to my situation.
The error code does not appear in any IB documentation I have been able to find.
?
What I do is very simple. For ES or NQ (mini futs) I enter a bracket, let's say to buy (LMT) with 2 OCA children, one profit-taking sell (LMT), the other sell STP.
I get filled and all looks good, two open orders appear. Let's call this state of affairs 1. If either gets filled, the other disappears as one would wish. So far so good. We can call this state 2.
But ... the problem occurs if in state 1, with the 2 OCA children still open, I decide to change the price in the profit-taking LMT.
That's when I get?
10326 OCA group revision is not allowed
The request is ignored, and the 2 OCA orders stay open unaltered.
?
This probably doesn't matter much, but my rationale for changing the price is to trigger the sell and close the position with minimal hassle, because my model views further waiting under the circumstances as unlikely to bear fruit. I suppose I could cancel and exit via MKT sell, but this seems simpler, more graceful, it used to work fine, and I miss those days.
?
I use ocaType=2, in case this is relevant.
?
Any help would be greatly appreciated.
?
?
|
´³¨¹°ù²µ±ð²Ô,
?
Thank you for your reply.
I am not sure how to answer your question about API level. I have API_Version=10.30.01 and a message 'serverVersion:177' pops up on the console when my (Python) client launches. TWS build 10.34.1c. Does this contain the answer? I should have probably mentioned this was happening in paper trading.
?
I am going to take a very close look at my order parameters.
?
But one thing that jumps out upon reading your post is that you do not appear to set ocaGroup, and it would further appear that the server does it. This stands in contrast to my approach of generating and setting ocaGroup explicitly.
I'm not sure whether this matters, but at this stage this is the only item that stands out for me, while everything else you describe sounds familiar and exactly as I think I am doing it myself.
To be honest I don't remember why I set ocaGroup. I wrote this execution engine some years ago, and it has served me well without any major overhaul, allowing me to focus on the analytics engine, which is the thing that decides what and when and sends it to EE. I expect I must have followed some example, possibly from IB online resources.
?
It also appears as though you are leaving the original parentId=2 when you modify the profit taker. That is what I used to do, but I have come across something in one of the posts from a fellow named Raoul:
'In the old situation, I always updated an oca child order with the same parameters, including the parentId . That no longers works. And the error message is actually helpful ;-) Leave parentId out when updating a child oca order when the parent has already been triggered. Worked for me.'
I thus tried setting parentId=0, to no avail.
?
I am going to do more digging now using the leads in your post and will update with any epiphanies that might reveal themselves.
|
´³¨¹°ù²µ±ð²Ô,
Pardon my ignorance, but when you say
'The Profit Taker order as updated by and received from IBKR'
how do you receive and examine the updated order details?
?
|
After you call placeOrder() for an order (or in the bracket case call it once for each of the three orders), IBKR keeps your client aware of the order progress through a variety of callbacks: openOrder(), orderStatus(), execDetails(), commissionReport(), possibly error().
The openOrder() callback provides you with an Order object that reflects all the information, IBKR has about the order. The Order object you receive in the first openOrder() callback after placeOrder(), for example, has fields such as clientId, accountId, permId, ocaGroup, ... initialized by IBKR. As the order progresses, subsequent openOrder() callbacks provide Order objects that reflect whatever change took place since the last call (quantity changes due to partial fill, trigger price changes for TRAIL orders, ....)
My framework instantiates (among others) a PositionController for each instrument the client places orders for. That controller:
- makes order objects and initializes the least number of required fields when an order is initially placed (what you see as "The original bracket order" in my post)
- receives all callbacks related to the order and monitors the order progress
- maintains copies of the updated and changed Order objects it receives from time to time from IBKR )what you see in "The Profit Taker order as updated by and received from IBKR")
When it is time to make a change to an already open order (in our case the Profit Taker order), my client simply makes a call such as changeLimitPrice(). IN that case, PositionController makes a copy of the last Order object it received through openOrder(), adjusts in the copy whatever needs to be changed (in our case the limit price) and calls placeOrder() with that order object.
That approach has the advantage that I never really have to worry about what IBKR needs initialized in order for order changes to work.
Hope that makes it more clear.
´³¨¹°ù²µ±ð²Ô
?
On Thu, Mar 13, 2025 at 11:49 AM, Max Payne wrote:
´³¨¹°ù²µ±ð²Ô,
Pardon my ignorance, but when you say
'The Profit Taker order as updated by and received from IBKR'
how do you receive and examine the updated order details?
?
|
´³¨¹°ù²µ±ð²Ô,
?
Success! And epiphany #1: when I skip setting ocaGroup (while keeping parentId as in initial order) the problem goes away. The execution engine is once again purring happily!
?
I appreciate your explanation of how you use openOrder(). I do use it (and the other callbacks you list) to track fills, cancellations, cross check positions etc., but it never occurred to me to look beyond .status and .totalQuantity.?
I am going to take a closer look at this as it has clear potential for debugging if nothing else. Some aspects of your PositionController have equivalents in my code, but this is a good opportunity for me to think it through again.
?
Thanks again, this has been most helpful.
|
I am glad that worked for you, Max.
Interestingly, just before your post I was able to reproduce? your issue by assigning an OCA group name AND by reusing the original profit taker order.
Apparently, TWS ignores the OCA group name from the initial order, still assigns a generic OCA group to the child orders, and returns Order objects with their generic OCA group names.
- Everything works just fine if you change the profit taker limit price with the IBKR provided Order object (and their generic OCA group name)
- But if you use your own order object with your OCA group name (a group that really does not exit and has no orders), Error 10326 "OCA group revision is not allowed." occurs since you technically are trying to change the OCA group the profit taker order belongs to. And that is not allowed. Come to think about it, the error message is actually right on.
And it is very well possible that this behavior was introduced by newer TWS versions. But that validates my approach of:
- Letting IBKR wrap the child orders of a bracket into an OCA group (as the TWS API documentation code sample suggests)
- Using IBKR provided Order objects for any order change
´³¨¹°ù²µ±ð²Ô
?
?
?
On Thu, Mar 13, 2025 at 02:31 PM, Max Payne wrote:
´³¨¹°ù²µ±ð²Ô,
?
Success! And epiphany #1: when I skip setting ocaGroup (while keeping parentId as in initial order) the problem goes away. The execution engine is once again purring happily!
?
I appreciate your explanation of how you use openOrder(). I do use it (and the other callbacks you list) to track fills, cancellations, cross check positions etc., but it never occurred to me to look beyond .status and .totalQuantity.?
I am going to take a closer look at this as it has clear potential for debugging if nothing else. Some aspects of your PositionController have equivalents in my code, but this is a good opportunity for me to think it through again.
?
Thanks again, this has been most helpful.
|
Your explanation makes sense, and it does vindicate the wording of the error message, which explicitly mentions OCA group.
|
Hi Jimmy thanks for the reply back in Nov.. curious if they ever got you a solution in ticket #804191? or if you got it working ever?
?
I've got an OCA Group type 2 and am trying to update stop price of one of the orders. Always getting this error:
Error 10326, reqId 40: OCA group revision is not allowed.
Set parentId = 0, unticked any api order protection.. no dice.
Going to try next using a different order object, rather than the original order I submitted, use the one passed back in the status.. sorta like ´³¨¹°ù²µ±ð²Ô alluded to. I'll report back if I find anything.
Anyway thanks in advance.
|
wordd