OK. RubberToe, bear with me …
You could send this (your last post and mine here) to the support instance you used the previous time, as they know it is me who is involved. Next, on your behalf I refer to Victor, who is working on 99% similar issues I have been exchanging with him (so far unsolved and on-going and with main ticket nr : Ticket#2021041610019716). This comprises :
We (you, me, anyone) hand an order to IB (which goes via the PRT platform) but IB does not respond sufficiently quick. I won’t put the burden on you of telling – and dealing with the thresholds, but let’s say 2 seconds for the example. Thus, if IB does not confirm your order (a cancellation of even a pending order is also an order) within 2 seconds, the PRT platform smells misery and it resets. Fun: this is on purpose and if I am correctly (self-)informed this happens because ever back I proposed this solution. The why of it is a longer story, so please never mind. Resetting, for me, is visible as a disappearing of all the orders (their tags/labels) and in a few secs them reappearing. And for you ?
For you this can-not work !
Assumed that the reset takes place for the API version just the same, it will imply an “impossible” situation for the TWS-PRT connection as such. Here a made-up scenario which may be telling, but which also should be telling for PRT support :
- You put in an order;
- IB responds too slow (this is a plain IB issue);
- PRT has to go for the safe side and it resets the platform so all will be refreshed (re-initialized);
- #3 will imply (wait, as per my own interpretation and knowledge) that the TWS-PRT connection will not be re-established easily, not at all or not automatically;
- From here follows that now IB can’t talk to PRT *but* which will not be a necessity for IB. Anyway, the live event will be missed (can be the confirmation of any kind of order, including cancellation). It would require another reset of PRT to get the statuses correct. But that won’t happen automatically because for PRT nothing is wrong. Especially not when she thinks the connection is there (see the other/earlier issue).
- Most probably because nothing communicates, your commands (new orders / cancellations) are stacked, but not really queued (think of proper sequence here).
This ends up in a mess you showed (it may).
A few more remarks :
In my own similar cases with normal connection, it will end up fine except for me having the orders twice. Anyway this shows fairly soon (like within a minute saying “oops !” to myself);
However, because things are wrong – or better went wrong, they can be analyzed by means of PRT’s logs (and by PRT); If this does not require a so-called Technical Report, they can analyze for you what happened, which at least will lead to the confirmation of your issues. The emphasis in this sentence is because no Technical Report (which is a system dump) can be made for the API version. … But the analysis from normal trade logs from your account, should lead to the conclusion that the reset-thing has to be set up differently for the API. So this is the message that should arrive at PRT development. That is, if I am correct in my assumptions.
Important :
See attachment; although I did not really check, this will be one of the higher-volatile long-ing/shorting stocks. It, for example, may not want to be shorted for a longer period of time, while you may have put in a Short order (it is a bit hard for me to see cause and effect in your screenshots). Thus, issue #1 may have been just that situation (orders staying Gray, which would be normal for this). Don’t ask me how the platform responds to this in the situation of the API. So that too has to be checked by PRT development.
Also, such situations are ones which require a bit of experience (which you may have in the first place) in order to tell you what is actually going on – up to wrong. Thus, an instrument which can’t be shorted because it is forbidden by the broker is one (ref. GameStop), but because of unavailability (no buyers elsewhere) is a clear other for these messy stocks/situations.
I even once had a situation that nobody was able to kill my pending Short order because it appeared that only me, in an other account with a Long position of the same, could allow for the pending order to be (IIRC) filled. Only after that I could easily exit it and I was freed of the situation. Thus just saying – it could be about that only … Or … it could be about that after the “reset” thing starting to create a mess which can’t be analyzed any more.
It is up to you what to do with this, but please notice it should be about the API only because else without the API already it is only IB to blame because of too slow responding and there already improvements on the PRT side are a bit necessary (mainly to avoid double orders without you knowing). … If this text arrives at PRT then I suppose it will be sufficiently speaking.
Peter
PS: I hope that situation got normalized by now ? (WKHS up 15% pre-market – haha)
.
.
