Async order sending and what comes back

[Fairman]

Async order sending and what comes back

In MetaTrader 5, an order can be sent synchronously, waiting for the server's answer, or asynchronously, returning immediately and delivering the result later through an event.

The synchronous call is simple. The program stops until the order is confirmed or rejected, which can take tens or hundreds of milliseconds. During that time, it can't react to anything else.

The asynchronous call frees the program to continue. It can send several orders in quick succession or handle price updates while waiting. The result arrives as a trade transaction event, which the code must handle.

The complication is state. After sending an async order, the program doesn't yet know whether it filled. If it assumes success and sends a second order based on that, errors compound.

Careful design tracks each order's status explicitly: pending, filled, rejected, partially filled. A state machine prevents duplicates and orphaned positions.

For strategies that need speed, async is the better tool. For simple ones, sync is safer.

The bug reports that come from async code are often about assumptions: the position wasn't there yet, the stop was set on a ticket that didn't exist.

Which order-sending mode is used in the automated systems, and what bugs came with it?

[FXS HongKong Scalper]

Async order sending and what comes back In MetaTrader 5, an order can be sent synchronously, waiting for the server's answer, or asynchronously, returning immediately and delivering the result later through an event.

Async sending is useful for EAs managing several symbols. The trade-off is that error handling becomes more complex, since a rejection arrives later through OnTradeTransaction. Without careful handling, an EA can think an order is live when it was rejected.