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?
Async order sending and what comes back
Async order sending and what comes back
It’s Fairman 