Keyboard Shortcuts
Likes
Search
TWS 10.30.1.e bug
|
Heads up.? New TWS 10.30.1.e from July 1, appears to have a problem.
If you just receive data / history for the market.. its OK. If you place an order, then the return order status, the message text, is prefixed with an extra byte.? This makes the header 5 bytes long, and then disaster follows trying to decode it.? All message sent from here on, have a 5 byte header.? (msg header is supposed to be 4 bytes). Even closing your app and restating it, the TWS API keeps the 5 byte header bug.? Only a TWS restart will clear the bug, until the next order. Enjoy |
|
My experience is slightly different.
There's indeed an extra byte, but it's part of the That extra field is in fact the One way to fix the issue is to update the client to the latest API version. |
开云体育Have you (or anyone else) reported this bug to IB? ? I was notified about this on 1 July by a user of my software, who is using the self-updating version of TWS. So of course, as soon as he started TWS, it updated to 10.30.1e, and he hit the problem almost immediately (my API implementation currently has a client version of 177). ? I assumed that IB would fix it pretty much immediately, seeing as it’s so obvious, but when I installed 10.30.1e today I immediately hit it myself. I presume IB’s testing doesn’t include ensuring it still works with down-version ?clients… (Or possibly their decoding method is immune to extra bytes, if they still split the buffer into discrete messages using the length bytes.) ? Updating my API implementation(s) to 185 is obviously a possibility, but it would be far better to have IB fix it, otherwise it may continue to happen with subsequent new versions. ? ? ? From: [email protected] <[email protected]> On Behalf Of noreply.section+dev@...
Sent: Wednesday, July 3, 2024 6:49 PM To: [email protected] Subject: Re: [TWS API] TWS 10.30.1.e bug ? My experience is slightly different. There's indeed an extra byte, but it's part of the That extra field is in fact the One way to fix the issue is to update the client to the latest API version. |
I haven't. On a side note, I'd like to point out that if a client is programmed to read off the wire the whole message (i.e. all the bytes specified in the header), it won't be negatively affected by the presence of extra fields: they will simply remain unparsed and discarded. I bet this is one of the main reasons why a header was added to the message protocol years back. On the other hand, if a client ignores the value in the header and just relies on the fields having a predetermined sequence, as it was the case when API < 100, it will be quickly thrown out of sync by any unexpected field and the rest of the communication will be unrecoverable. This is clearly a TWS bug, however its severity could be completely mitigated by some defensive programming. |
|
I don't have any working emails to contact them with.? Who do we write too?
The whole API is supposed to be version aware, both forwards and backwards, and normally it is. In my testing and code, if there was an extra byte (unexpected) added to the last msg, and it was not read / interpreted, it would get shifted to the front of the local storage as unread and the next msg blob would append to it.? But it does not happen, which tells me the extra byte is inserted by error into the send stream of internal TWS and turns up into the header frame.?? Also confirming this, if you generate the fault, then kill and restart your app (but not TWS), then ALL msg headers have the extra byte inserted, from the very first connect msg and onwards. So I don't feel its bondaccruedinterest field lingering around is the issue. Does anyone have a proper email for the API team? |
开云体育Ross ? You say: ? Also confirming this, if you generate the fault, then kill and restart your app (but not TWS), then ALL msg headers have the extra byte inserted, from the very first connect msg and onwards. ? But that’s not my experience at all. My first order today caused this erroneous ORDER_STATUS message, and crashed my API program. TWS has been running all day, and I’ve been using other client programs (with different client ids) with no problems at all, as long as they don’t place orders. If I restarted the failed API client, it again generated the invalid ORDER_STATUS message because I have the API configured to download open orders and executions on connect (and the order was still open at the time). If I then manually completed or cancelled the order so it was no longer open, I could then run a client program with that client id with no problems (as long as it didn’t place orders, of course). ? I haven’t yet been able to determine whether the 4-byte length header for the OPEN_ORDER message is correct (ie that length includes the extra byte). ? Assuming that length is correct, I think I’m going to update my implementations to defensively ?ignore any extraneous bytes at the end of API messages. This seems to be straightforward to do, and will get me over the hump with 10.30.1e. ? Nevertheless IB should fix this bad behaviour, so if I get time tomorrow I’ll try to email the address that rwk suggested (unless anyone has already done this). ? Richard |