Thanks, that is helpful
I had position = 800, order to sell 800, it initially filled 692/800
115708.497 positionEvent, position=108
115708.506 execDetailsEvent, Fill shares=692, cumQty=692, fill time=115707
115708.508 trade.fillEvent, Fill shares=692, cumQty=692, fill time=115707
115708.520 orderStatusEvent, filled=692
115708.535 execDetailsEvent, Fill shares=108, cumQty=800, fill time=115707
115708.537 trade.fillEvent, Fill shares=108, cumQty=800, fill time=115707
115708.540 orderStatusEvent, filled=800
Never received positionEvent, position=0
My current logic, which tries to work around the positionEvent bugginess, but is flawed, marks my position as verified if the positionEvent matches either all fills since the last verified time or an updatePortfolioEvent. In this case,
start: position = 800, verified
The first positionEvent sets position = 108, not verified
The first execDetailsEvent with the 692 fill makes it go back to verified as of the positionEvent time of 115708.497
The second execDetailsEvent with the 108 fill arrives, but the fill time of 115707 is before the time I verified the position, so I ignore it. This is wrong because the first positionEvent arrived after the remaining fill, even though it did not include it.
It sounds like I should just assume positionEvent is flawed and ignore it and only rely on execDetailsEvent or trade.fillEvent. Does that sound right?
