Two orders with the same ticket number - page 2

[yoriz]

fxsaber #:
Bug reproduction.

Thank you for taking the effort to reproduce the problem! So the problem is in the MT5 platform, not in my code.

But if we can not trust CTrade::ResultOrder() to return the ticket corresponding to the order we just opened, then what should can we do?

- Should I just ignore CTrade::ResultOrder() and only use the OnTradeTransaction callback?

- Should I complain at MetaQuotes and ask them to fix the bug?

- Should I iterate over all open orders and try to find back the newly opened order?

[fxsaber]

yoriz #:

But if we can not trust CTrade::ResultOrder() to return the ticket corresponding to the order we just opened, then what should can we do?

- Should I iterate over all open orders and try to find back the newly opened order?

This. I don't use OnTradeTransaction. To detect desynchronizations, I read the trading environment every time (Positions, Orders, History).

[Lorentzos Roussos]

i think in this case if you set the BuyTicket to 0 and return instead of break when the case is 

TRADE_RETCODE_DONE_PARTIAL

it will work as a temp fix

It won't work as the return code is Done with the ticket from the other VPS as @fxsaber demostrates below

[Lorentzos Roussos]

fxsaber #:
Bug reproduction.

Wow.

What happens if you print the retcode as well when an order is found not by the magic of the EA before ExpertRemove() ?

(if its DONE or PLACED it can't be filtered out in other words but if its something else) 

[fxsaber]

Lorentzos Roussos #:

What happens if you print the retcode as well when an order is found not by the magic of the EA before ExpertRemove() ?

Full Logs.

[Lorentzos Roussos]

fxsaber #:

Full Logs.

Yeah i mean 

    if (OrderGetInteger(ORDER_MAGIC) != inMagic){
     Print("Broker Retcode ["+IntegerToString(Result.retcode)+"]"); 
     ExpertRemove();
     }

How likely is it that the broker is saying :

"Hey , you have an order on this symbol on this price already"

[fxsaber]

Lorentzos Roussos # :

Yeah i mean 

#define TOSTRING(A) (" " + #A + " = " + (string)(A))
  
  ResetLastError();
  if (OrderSend(Request, Result))
    Print(EnumToString(Request.action) + ": true." + TOSTRING(_LastError) + TOSTRING(Result.retcode) + TOSTRING(Result.order));
  else
    Print(EnumToString(Request.action) + ": false." + TOSTRING(_LastError) + TOSTRING(Result.retcode) + TOSTRING(Result.order));

 2023.01 . 17 16 : 12 : 22.095 Test5- 3 (USDCNH,H1)     TRADE_ACTION_PENDING : true . _LastError = 0 Result.retcode = 10009 Result.order = 50327466301

The function was supposed to return 50327466302, but returned 50327466301 (Result.order).

[Lorentzos Roussos]

fxsaber #:

The function was supposed to return 50327466302, but returned 50327466301 (Result.order).

I see , yeah its 100% mq error . Thank you 

(so his only defense is the magic # ,in theory )

[yoriz]

fxsaber #:

This. I don't use OnTradeTransaction. To detect desynchronizations, I read the trading environment every time (Positions, Orders, History).

@fxsaber, thank you for your advice.

Some of my strategies must act very fast on each tick to update a very tight trailing SL. My most extreme trade lately was only open during 20 seconds, did 30 SL modifications in that time and made 1740 euros profit.

I am worried that reading the trading environment on each tick is too slow. Will that not take a lot of time?

[yoriz]

Lorentzos Roussos #:

I see , yeah its 100% mq error . Thank you 

(so his only defense is the magic # ,in theory )

I don't trust anything anymore. If the ticket is invalid, the magic number might also be invalid.

I am disappointed in the MT5 platform. I did not expect a race-condition bug in a platform that must handle millions of ticks, hunderdthousands of orders, thousands of accounts, 24/7 day and night.

For me this was a very expensive way to learn about a bug in the MT5 platform. I don't think I can ask my money back at MetaQuotes?