Can you do the following:
1. Request open positions at startup
2. Just track the status of orders while ignoring position messages
3. Using the status of the orders, update your own internal list of
positions
This seems to work for me even with complicated partial fills. Note
that sometimes when I am manually trading with the TWS I can see a
lag between execution and position updates. Several months ago the
position entries lagged for several seconds at a time. So yes, the
position and order status events are definitely independent of each
other.
If the two types of events cannot be correlated in time, then just
use one to recreate the other. It seems like knowing the positions
at startup, and then tracking all order status events thereafter is
good enough to know the correct state at all times. Please correct
me if my logic is wrong.
Thanks,
Carl
--- In twsapi@y..., "grozzie2" <grozzie2@y...> wrote:
TWS is an event driven beast. No functions actually have any kind
of
return to validate they actually did something, everything waits
for
callbacks, to say events occurred.
Event driven models are great, provided, the event source reports
the
events in the actual order they occur. TWS does not.
If you are basing code on the events from the TWS activeX
component,
and building up logic for handling orders etc on it, be warned, I
have a captured log with the following sequence of events, and I'm
pondering what to do with it.
The state begins with a short position of 20 contracts in the es
minis. The program has a target cover buy in place, and a stop,
for
20 contracts each, and joined as a one cancels all group.
Event 1 - TWS reports partial fill for 11 from target order
program modifies internal structures to show -9 left in the
position, with 11 bought.
Event 2 - TWS reports current position on ES as -9
program verifies this as correct.
Event 3 - TWS reports partial fill for 9 contracts, order filled
completely.
program modifies internal structures to show target order filled,
and
removed from the operating state.
Event 4 - TWS reports current position on ES as -9 contracts
program goes HUH ?????????
program realizes, all buy orders are filled, and it still has a
short
position of 9 contracts, places an order to buy 9 to cover.
Event 5 - TWS reports order to buy filled.
program modifies internal structures to show buy now filled, and
position back to 0
Event 6 - TWS reports position of 0
program verifies this is the correct position
Event 7 - TWS reports current position on ES as 9 contracts
program emits expletives into the debug log.
Computers are fast, and can react much faster than humans. What's
important to note in the above sequence, TWS reported a WRONG
position, and the program reacted. The position reported was
correct
for the time BEFORE the second fill report, and this is
significant,
because TWS reported the -9 position TWICE, once before, and once
after the fill for 9. It looks to me like the TWS internal state
on
actual position size got delayed, and would have 'caught up' had my
program waited longer before doing order/position reconciliation.
A
human cant react that fast, so if it displayed -9, and updated that
display to 0 a fraction of a second later, or even a couple seconds
later, a human would go 'great, filled'.
2 weeks ago, I realized, TWS events are not necessarily in
sequence,
and had settled on the position report event as the 'atomic' point
of
action, on the assumption, it would be the one event we could count
on to report things, and if we postponed all position management to
that event, everything would stay in synch. Up until now, it's
appeared that would work, but now i see it wont.
I now have logs of various orders of events during the process to
prove, without any possibility of it being otherwise, there is no
TWS
event that you can rely on as an atomic thing, ie, it will be
correct. I have fills updated before positions, positions updated
before fills, and now i add to it, position reported late, or in
error. For now, i'll assume it was late, because if it was
actually
in error, and TWS was not going to follow the second -9 report with
a
0 report, then it will not be possible to build a 'safe' program
using this.
I can say the following with a certainty now. TWS is 2 or more
independant state machines internally, reporting events with no
relationships in time or order of events. If you are trying to
reconcile the events, and take actions based on the reports from
tws
in real time, at the time of events, then the following holds
true.
If you are trading more than quantity 1, at some point in time, you
will recieve event notifications that will come in an order that
breaks your logic. I have drawn out carefully the timing diagrams
from a number of event sequences in the area of partial fills, both
on entry and on exit. The last one provides a proof, there is no
event from TWS that is atomic, on which you can base decisions to
manage existing positions, and reconcile with fill reports. The
TWS
position reports are independant of fill reports, and there will
ALWAYS be potential for discrepancies. The only way to do a
reconciliation, is to postpone it until a point in time that you
can
verify there are no potential outstanding events.
It's time to re-design here.