In live the EA places duplicate trades sometimes

[Hendrik Piiriste]

Hi,

Very odd anomaly is happening.

In my backtest the EA trades as programmed, one trade per day, but sometimes it places two trades in live with in one second time difference and open price is only few pipettes apart.

When I backtest the exact date of the duplicate trades, then it places a single trade. But the price is of course different for backtest than it is live.

I had two hypotheses.

1. OnTick is triggered asynchronously and would place trades at the same time. But the document clearly stated that new ticks are ignored while a tick is being processed.

2. Then I figured that perhaps the EA finishes the tick before the trade is actually executed and the new tick would see that no trades exist and would therefore also execute a trade. But the EA is waiting for the response of the order before finishing the tick, therefore the trade must have executed before new tick started.

Now I do have about 20 different pairs open and running, but no pair has duplicate chart active.

So far the duplication have happened for different pairs.

Any idea what else could be causing the issue?

Thank you,

Hendrik

[Dominik Egert]

Hendrik Piiriste:

Hi,

Very odd anomaly is happening.

In my backtest the EA trades as programmed, one trade per day, but sometimes it places two trades in live with in one second time difference and open price is only few pipettes apart.

When I backtest the exact date of the duplicate trades, then it places a single trade. But the price is of course different for backtest than it is live.

I had two hypotheses.

1. OnTick is triggered asynchronously and would place trades at the same time. But the document clearly stated that new ticks are ignored while a tick is being processed.

2. Then I figured that perhaps the EA finishes the tick before the trade is actually executed and the new tick would see that no trades exist and would therefore also execute a trade. But the EA is waiting for the response of the order before finishing the tick, therefore the trade must have executed before new tick started.

Now I do have about 20 different pairs open and running, but no pair has duplicate chart active.

So far the duplication have happened for different pairs.

Any idea what else could be causing the issue?

Thank you,

Hendrik

How do you verify that there is a open position already?

History is updated after the fact you opened successful a new position. This is asynchronous.

So what seems to happen is, you successfully open a position and receive immediately a backlog tick call, before history is updated.

I suggest, you introduce a state variable, milliseconds time and set it after opening successfully a new position, and before opening a position you check if it is at least maybe 5 seconds old.

That would maybe be enough to ensure update on history, and your check of open positions should work reliable again.

[Hendrik Piiriste]

Dominik Christian Egert #:

How do you verify that there is a open position already?

History is updated after the fact you opened successful a new position. This is asynchronous.

So what seems to happen is, you successfully open a position and receive immediately a backlog tick call, before history is updated.

I suggest, you introduce a state variable, milliseconds time and set it after opening successfully a new position, and before opening a position you check if it is at least maybe 5 seconds old.

That would maybe be enough to ensure update on history, and your check of open positions should work reliable again.

I keep the state in memory.

In case of successfully opened position I add it to the positions list.

After a new tick arrives I check against that list, if I have open positions or not. This is due to the relations between multiple positions and as I cannot rely on the comments on the positions, then I have decided to manage them on my own.

As I'm not checking against the history, then I suppose it excludes the relevancy in delay of history registry?

[Dominik Egert]

Hendrik Piiriste #:

I keep the state in memory.

In case of successfully opened position I add it to the positions list.

After a new tick arrives I check against that list, if I have open positions or not. This is due to the relations between multiple positions and as I cannot rely on the comments on the positions, then I have decided to manage them on my own.

As I'm not checking against the history, then I suppose it excludes the relevancy in delay of history registry?

Obviously.

Then your own checks are failing somehow.

Write a log to know what's going on. Log the opening and print the state of your ticket list before and after opening. Then check why it is not matching.

[Hendrik Piiriste]

Dominik Christian Egert #:

Obviously.

Then your own checks are failing somehow.

Write a log to know what's going on. Log the opening and print the state of your ticket list before and after opening. Then check why it is not matching.

Will do so.

Tho, if it is not doing duplicate trades in backtesting. Do you have any idea what differs in the process? Besides the history registration that you explained earlier.

[Alain Verleyen]

Hendrik Piiriste #:

Will do so.

Tho, if it is not doing duplicate trades in backtesting. Do you have any idea what differs in the process? Besides the history registration that you explained earlier.

Because in a backtest there is no delay to get an answer about a trade/order request.

" But the EA is waiting for the response of the order before finishing the tick, therefore the trade must have executed before new tick started. "

No. Your assumptions are wrong. Your EA is certainly not waiting the response, please read the documentation again, and show the relevant code to confirm it.

So no "the trade must NOT have been executed before a new tick". Trade/Orders and ticks are 2 different things. They can or can not be "ordered".

[Hendrik Piiriste]

Alain Verleyen #:

Because in a backtest there is no delay to get an answer about a trade/order request.

No. Your assumptions are wrong. Your EA is certainly not waiting the response, please read the documentation again, and show the relevant code to confirm it.

So no "the trade must NOT have been executed before a new tick". Trade/Orders and ticks are 2 different things. They can or can not be "ordered".

This is the documentation I read https://www.mql5.com/en/docs/event_handlers/ontick and this is the line in particular "All events are handled one after another in the order of their receipt. If the queue already contains the NewTick event or this event is in the processing stage, then the new NewTick event is not added to mql5 application queue. "

But you are correct regarding the order execution. I haven't found in documentation that process would wait for successful order execution.

I think I have found my problem, but will need to live test a bit more to verify. Then I will post an explanation. :)

[Hendrik Piiriste]

I partly solved the issue.

Previously i only checked with PositionSelectByTicket, if the order I placed was active. But apparently the broker is slow execute the order and it will return false for a while. So I started to check OrderSelect also, which lowered the double trades. But now I got a trade where both  PositionSelectByTicket and  OrderSelect returned false while the ticket number was active apparently.

Is there another step of order execution that I can check?

[Dominik Egert]

Hendrik Piiriste #:

I partly solved the issue.

Previously i only checked with PositionSelectByTicket, if the order I placed was active. But apparently the broker is slow execute the order and it will return false for a while. So I started to check OrderSelect also, which lowered the double trades. But now I got a trade where both  PositionSelectByTicket and  OrderSelect returned false while the ticket number was active apparently.

Is there another step of order execution that I can check?

Since order execution is a asynchronous process, you will have to deal with the responses from "the other side".

MQL supports two Event Handlers to do so.

Take a look if this will help you:

https://www.mql5.com/en/docs/event_handlers/ontrade

https://www.mql5.com/en/docs/event_handlers/ontradetransaction

Basically, if you implement the process correctly, you should at all times be able to tell the current state. Beginning by placing an Order with either OrderSend or OrderSendAsync, and then tracing the events until it is fulfilled from the other side, and your terminal catching up, showing you the actual position.

You will have multiple events along the processing pipe.

It takes quite some code actually to trace the events, but you need to be aware, your code is, compared to what you see and experience when doing it manually, executing much faster, and therefore your code will be "waiting" most of the time for a response from the underlying system. Just the network roundtrip times, iE 100ms, will be like aeons for your code. And this is without processing times of any software in between.