5 strategies stopped this morning!

• 02/19/2018 at 10:52 AM #63123
  Despair

  And it happened again! Like last weekend again two strategies stopped with the message “This trading system was stopped because the broker could not confirm the status of the last order.”.

  Both strategies had open positions at the time that were closed. 🙁

  

  Despair

  Blocked

  Topics: 97

  Replies: 1034

  Been thanked: 218 times
  06/07/2018 at 11:53 AM #72547
  random45689

  Hi Ulrike

  Shouldn’t it be the PRT side of things that deals with this issue?

  I have been aware of this for a long time as I work on the 1 second timeframe (lack of multi-timeframe support/adjust code accordingly to actually execute trades on higher timeframes yet taking advantage of quicker order execution from the 1 second timeframe the code is running on) and often but not always when opening an order I will experience multiple orders in quick succession with one cancelling the other until one ‘sticks’

  I gradually concluded that it was happening when PRT code was submitting an order but IG was not confirming the order within the 1 second timeframe and so the PRT code was sending another request which then cancelled the previous order as a ‘one close other’ order

  Happens either when there is no bar on a particular second/for a few seconds

  I coded in a delay to ‘wait’ for the confirmation of the order which is basically having the line ONETRADE=ONETRADE+1 at the top of the code and the following for order entry

  IF NOT ON MARKET AND ONETRADE<=1000 AND POSITIONPERF(0)=POSITIONPERF(1) THEN

  The reason for the 1000 (can’t remember the reason for the positionperf but it was also necessary) is that it would seem in fact the code does not quite run as it would in demo PRT using graph function – ONETRADE would only get to 1 – but in live environment it can be tested and confirmed that 1000=1second so it would seem these are milliseconds

  This works in a strategy that I only want one trade in total to execute and run – when I start the code if an order is not placed in time then it does nothing and just sits there until I stop and restart the strategy and try it again until it works

  So as said shouldn’t it be the PRT side of things that deals with this issue not the broker and at least not error out and frustratingly stop the strategy?

  Thanks

  Max

  

  random45689

  Member

  Topics: 11

  Replies: 168

  Been thanked: 39 times
  08/03/2022 at 11:00 AM #198409
  Batty

  Ulrike   I appreciate I am posting this on an old thread. I have been experiencing an increasing number of instances of “This trading system was stopped because the broker could not confirm the status of the last order” … to the point it is rendering the results of my demo account meaningless. I have not had the same problem on my Live account even when running identical systems. I have read everything I can find on the subject and while it appears the issue is still causing problems this year, the underlying conclusions appear to be that it is down the PRT system and IG have not in fact resolved the issue.

  You mention in your post of  02/15/2018, that there is a workaround for demo accounts, soon to be made available for live accounts. I cannot however find any information on what the workaround is / how to employ it on my systems. It would be a real help if you could give me more details on this.

  Many thanks for your help,

  Kevin

  

  Batty

  Participant

  Topics: 6

  Replies: 76

  Been thanked: 36 times
  08/03/2022 at 11:34 AM #198412
  GraHal

  Batty wrote:

  could not confirm the status of the last order

  I get loads of above error, but seems to be in fits and starts … like none for a week or 2 then loads in 1 day.

  I have never found out exactly what – could not confirm the status of the last order – means / is the cause?

  In my opinion (I’d love to be proven wrong) it’s a ‘catch all’ when none of the other (often meaningless) error messages apply!? 🙁

  EDIT / PS

  I’ve just had a logical idea …

  We get – could not confirm the status of the last order – when the Demo servers can’t keep up with volatility and so the PRT engine can’t read quick enough if the last order has executed or not and so another order cannot be placed and so the System is Rejected??

  

  GraHal

  Participant

  Topics: 214

  Replies: 8830

  Been thanked: 2200 times
  08/03/2022 at 12:01 PM #198414
  Batty

  GraHal wrote:

  I’ve just had a logical idea … We get – could not confirm the status of the last order – when the Demo servers can’t keep up with volatility and so the PRT engine can’t read quick enough if the last order has executed or not and so another order cannot be placed and so the System is Rejected??

  This does seem logical and broadly ties in with my experience with this error. And it seems to go in fits and starts with my systems too.  Recently it has been really bad.

  Could it also be the case that it occurs simply of the demo servers get overloaded with exactly the same order being made / adjusted all at exactly the same time?  So in effect the same result as high market volatility – the Demo servers can’t keep up.

  I have an open case on this at present via IG tech support. I’ll update here on whatever feedback I get.

   

  1 user thanked author for this post.

  GraHal

  

  Batty

  Participant

  Topics: 6

  Replies: 76

  Been thanked: 36 times
  10/28/2022 at 2:46 PM #203157
  Batty

  We finally got to the bottom of this problem (frequent stoppages due to “broker could not confirm the status of the last order“).  It is a known problem as per the note below from their tech support i.e. each time it is due to latency of the SocketServer. So much as you thought GraHal 🙂

  I believe this is specific to demo accounts and, as per the note below, should be fixed in January.

  =========

  COPY OF NOTE FROM TECH SUPPORT

  The strategy has stopped due to the latency of the SocketServer.
  As you can see below, we send you a Close order at 12:21:25 and you sent us the confirmation of the execution at 13:03:15.
  More than 40 minutes after we sent the order. Because of this latency the strategy was stopped.

  In my case it has been triggered regularly by one particular element of code that I used across a number of systems (using STOP and LIMIT orders in a 13 min updateonclose timeframe, on a 1 minute underlying chart). Other systems do sometimes trigger the problem, but much less frequently. I tried multiple workarounds most of which worked. So, while the  underlying problem is the demo servers, if anyone is experiencing it regularly with particular systems, it could be an element of the code that is triggering it and there may be a workaround until the underlying problem with the servers is fixed.

  I hope this is useful.

  2 users thanked author for this post.

  robertogozzi, GraHal

  

  Batty

  Participant

  Topics: 6

  Replies: 76

  Been thanked: 36 times
• Author
  Posts