IB "Can't find order with id" messing me up

F

foible

I've been having a recurring problem with IB where one of the orders in a OCA group randomly (?) fails to transmit. Sometimes this means that one of my stops or targets doesn't get sent which is irritating, often this means that the entire group doesn't get sent which is worse. I've sent several e-mails to api@... and after advising me to turn logging onto DEBUG, they haven't replied.

When I check my logs and the DEBUG logs of TWS, the working & failing orders look the same but for the failed orders I get the error message code 135, "Can't find order with id =".

I'm using the same code to send all of my orders so it is a real mystery why sometimes I get these errors and sometimes it all works smoothly.

IB isn't any help. Has anyone here seen this before? Does anyone have any suggestions for debugging an app like this - the DEBUG logs of TWS aren't shedding any light and the error logs of my app don't give any more info either.
 
Never had any problem.
Suppose I am long one stock and want to had one stop and one limit I make a buy stop and sell limit and I just give them BOTH the SAME OCA name that is the same, lets's say "Stock1".
I do the same in my Excel API no problem.
I send the orders after execution so I dont have to bother with a bracket order where the orders auto trigger when the "middle" order get filled.
I dont feel like helping you but this thing is supposed to work. Maybe you are doing something wrong.
 
(I am assuming that since it works sometimes, you know how to send OCA orders and this is most likely a bug).

I have discovered inconsistencies in IB api behavior before... the guy running the api tech support is very junior (raymund), and like many junior people he avoids dealing with problems he doesn't have an easy answer for.

It seems like his main obstacle is he doesn't like to *disturb* the developers. The way to get around this is to use the debug logs, code that will reproduce your problem and graphics... whatever... just use data to present the inconsistency clearly and he can then pass this over to the developers.

this way they will open a bug for your issue and fix it in the next release.

Raymund is a nice guy, but I think he is sort of alone and he doesn't know how to ask for help... but if you build a case for him and are persistent, it can get done.
 
I have seen this before using Sierra Chart to trade with IB's API. Sierra Chart's developers say it has something to do with a symbol mismatch and how IB manages the symbols. I have not been able to get a clear answer but it happens to me sometimes when connectivity is lost and then re-established to TWS.
 
I have had this...very annoying...

My best guess is that the initial order is filled before the
trailing stops/bracket orders arrive on the IB server.

So they go to look for the orderid specified and cannot find
it since its already filled.

Come to think of it...it may be the way the orders are transmitted. In TWS, you would build all orders and transmit as a group.

Are you transmitting the orders separately or together?
 
Had a problem like this several years ago. Orders have to be accepted in the proper sequence relative to the order ids. So even though I might send orders in the proper sequence as in order id 1,2,3. IB might accept order 3 first and reject 1 and 2 because they don't have ids higher than 3. My first approach was to add a longer delay before sending in the next order, however while that approach greatly cut down the number of times the error would occur, it did not eliminate it completely. I ended up having to write a bunch of code to reassign order ids and resubmit rejected orders, until all orders have been accepted correctly.
 
I'm going back in for another round of programming. My plan is to use the account feedback before assuming the strategy knows anything at all about what is up with the orders. Ex: An entry order will be sent but the code that places the bracket OCA won't execute until I get a fill confirmation from the entry order. If that doesn't work I'll use the delay ideas others are using... I like the feedback though, it's "tight". The downside would be if TWS is slow to report..

There are some discussions on the Ninjatrader forums about IB API problems that are enlightening. Ray informs about some things that just don't work right and some suggestions.
 
Quote from Fractals 'R Us:

Ex: An entry order will be sent but the code that places the bracket OCA won't execute until I get a fill confirmation from the entry order.
More...

Yeah, I coded mine to do exactly that. However, I still recommend adding additional code to verify that child orders get submitted and accepted properly. I really wish IB did a better job at handling API bracket orders. But as it stands, it requires lots of additional coding by API users to successfully submit bracket orders.
 
Adding the 300ms delay sounds like it could be a winner. As some background I had my bot working with the IB datafeed without any problem and when I moved to IQFeed this bug showed its head. I have suspected it could be that the data feed isn't providing that "choke" so I'm able to push through more orders, faster and there's some synchronization issue cropping up. I'll add in a time delay and see if that helps.

Will let you know...


Re OCA groups - Initially I was having a problem with the transmit of OCA groups but when I set transmit=false for all orders and transmit=true only for the last order, that worked well. Instead of creating my own OCA group ID I'm just setting the parentId to the initial entry order which is a great help. The docs aren't very clear but some comments here on ET steered me straight :)


Re IB support reps - I don't mind a bit of a lag since they're understaffed but they've taken to ignoring me (seemingly). It will soon be four weeks since they replied to my first e-mail asking me to send in DEBUG logs. Since then I've sent three replies with more information, screen caps, logs and more detail but they haven't replied once. I even chatted with tech support who said they'd bug the API guys. A simple "we're busy but we haven't forgotten you" would at least tell me that there's a queue and they'll eventually look at it but I haven't gotten anything. Most frustrating.
 
You must log in or register to reply here.
Back
Top