Inconsistent OrderSend behavior during ERR_NO_CONNECTION

New comment
 

Hi,

I have observed a case where 'OrderSend' function returned a non positive int indicating it had failed; and GetLastError() returned 6 indicating ERR_NO_CONNECTION, however it had actually submitted the order. My code assumed ERR=6 as a temp failure and retried an OrderSend, and succeeded, and now I have two orders with the same Magic Number.

In the journal log I see:

17:19:04.071 '31713715': pending order buy stop 0.01 GBPUSDpro at 1.67714 sl: 1.67205 tp: 1.67944

17:20:43.458 TradeContext: ping error


 I think what has happened is there was a connection interuption just as the order was sent, so the response was not captured, so from MT4 side it appears as the connection went down. 

Looking at logs this Order Ticket number just appeared out of no where, it does not appear in the journal log at all. My code assumes that the order ticket will be returned by the OrderSend function so that it can keep track of it etc.

Is this normal behaviour? It is the first time I have observed OrderSend submit an order without returning a valid ticket number. Any thoughts/suggestions in handling this sort of scenario?

 
  1. Don't assume. On the next tick, get the status. You need to anyway to know when orders close.
  2. I expected it to return ERR_TRADE_TIMEOUT. It can't know the result because the connection was down. Perhaps that code only occurs when the server doesn't respond but the network is functioning.
  3. My handling of ALL errors is to log them, return, wait for the next tick, get updated status and retry.
 
WHRoeder:
  1. Don't assume. On the next tick, get the status. You need to anyway to know when orders close.
  2. I expected it to return ERR_TRADE_TIMEOUT. It can't know the result because the connection was down. Perhaps that code only occurs when the server doesn't respond but the network is functioning.
  3. My handling of ALL errors is to log them, return, wait for the next tick, get updated status and retry.


1. I already grab order status, hence how I discovered this because the code flagged the duplicate order that did not have a linked ticket number.

2. Connection interruptions are inevitable. So this is out of our control :)

3. During failures, I ended up simply checking the order book if a new order had been submitted recently and if it matched fetch its ticket.

 

However this all should be unnecessary. In an ideal world, the sending system (MT4 client) should handle retries on failures, and the receiving system should handle duplicates, ie the MT4 server. How? With the use of a unique ID. All sane transactional interfaces follow this convention :) 

New comment
Reason: