Reliable Telegram-to-MT4/MT5 Delivery: Idempotency, ACKs, Retries and Recovery

Reviewed: August 13, 2026.

Reliable Telegram-to-MT4/MT5 delivery is not the same as fast message forwarding. A message can be parsed correctly and still be duplicated, delayed, lost between network hops, rejected by a terminal, or acknowledged too late. The useful engineering question is: what state does the system keep at each boundary, and how can it recover when that boundary fails?

This guide describes the application-level delivery model used for the EA bridge in TelegramToMT5Copier. It is an educational architecture explanation, not a service-level guarantee or a claim of exactly-once broker execution.

Scope and safety boundary

The system is software for parsing, routing, and recording user-configured trade instructions. It is not a broker, signal provider, or financial adviser. Delivery controls cannot verify that a signal is profitable, appropriate, or compliant with a broker or funded-account rule. Network availability, Telegram, MetaTrader, broker execution, market movement, account settings, and the user's environment remain outside a single application's control. Read the Trading Risk Disclosure before using any automated execution workflow.

The delivery flow

The bridge treats a trade instruction as a stateful command rather than disposable text. A simplified flow is:

Telegram event
  -> source, licence and message checks
  -> parse and safety filters
  -> account-specific queue + opaque command ID
  -> authenticated EA pull
  -> terminal validation, duplicate check and broker request
  -> ACK with the same command ID and an execution result
  -> queue removal + audit-log update

Parallel telemetry path:
MetaTrader account report -> current account snapshot + bounded history

The pull response, execution acknowledgement (ACK), and account report serve different purposes. Pull transfers work. ACK closes the lifecycle of a particular command. Report carries account telemetry and history; it does not prove that a specific command executed.

1. Command identity is the correlation anchor

Each queued account command receives an opaque command ID. The same ID follows that command into the pull response and comes back in the EA's ACK. The trade log stores command IDs so a delivery can be correlated with its parsed signal, account, delivery attempts, execution status, ticket identifier when available, and error message.

Identity matters when the network outcome is ambiguous. If the EA executes a request but its ACK is lost, generating a new command ID for every retry would make the retry look like unrelated work. Retaining the same command object and ID lets the sender and receiver recognize the retry as the same delivery attempt.

2. ACKs separate delivery from execution

A successful HTTP pull only means that the EA received a response. It does not mean that MetaTrader or the broker accepted an order. For open commands, the queue marks the command as awaiting acknowledgement and records delivery timestamps and an attempt count. The EA then returns a positive or negative result for that command ID.

• A positive ACK updates the associated trade log as executed and can include timing and a ticket identifier.
• A negative ACK records a failed execution and its error message.
• After either result is processed, only the acknowledged command IDs are removed from pending queues.

This distinction also prevents account telemetry from being mistaken for an execution receipt. A fresh balance report is useful operational evidence, but it is not a substitute for a command-level ACK.

3. Retries use the same open-command ID

An unacknowledged open command is retained. It is not returned again during a configured retry quiet period. After that interval, the same command object and ID can be offered again. This is an at-least-once delivery pattern: it favors recovery from a lost response, while receiver-side duplicate checks reduce the chance that recovery creates another position.

The current EA checks its trade correlation identifier before opening. If a matching trade is already present, it ignores the repeated open request and sends a successful ACK marked as a duplicate rather than opening it again. This pairing is important:

retryable sender + stable command identity + receiver duplicate check
= recoverable delivery with duplicate suppression

That is not a mathematical guarantee of exactly-once execution. The application and an external broker do not share one atomic transaction. A design should therefore make retries safe and observable instead of assuming that every network response is definitive.

Open commands use retained ACK-aware delivery. Legacy management commands such as updates are treated as one-shot after pull, so tests and operational expectations must distinguish command types.

4. Expiry prevents indefinitely stale execution

Commands are checked against a configured maximum age before delivery. A command that expires without ever being pulled is recorded differently from an open command that was delivered but never acknowledged. Delayed commands use their scheduled execution time as the freshness reference, so an intentional delay does not consume the whole freshness window before the command becomes eligible.

Expiry is a safety boundary, not evidence about market quality. It stops the queue from retrying an old instruction indefinitely; it cannot decide whether a newer instruction is sensible.

5. Telegram recovery happens before command delivery

The inbound side has a separate recovery problem. Live Telegram events and background polling share a per-channel serialized work queue. The system records message keys and a per-channel cursor. If a live message ID reveals a gap, it requests messages after the stored cursor and before the live boundary, sorts them in message order, removes repeated IDs, and processes the missing messages before the live one.

If immediate gap recovery fails, the earlier cursor is retained so a later polling pass can try again. Seen-message keys prevent the current live event from being handled twice when polling catches up. Recovered messages also have an age limit; an old recovered message is marked seen and logged as skipped instead of silently becoming a fresh trade instruction.

An optional semantic duplicate window adds another layer for two messages that carry equivalent trade values but do not share the same Telegram message ID. It complements transport deduplication; it does not replace the command ID and ACK lifecycle.

6. Execution leases are different from retry timing

A retry quiet period answers, "when may this unacknowledged command be delivered again?" An execution lease answers a different question: "is this exact risk-reviewed command still authorized under the matching account and policy state?"

Where risk preflight is enabled in the local-client path, the bridge binds a short-lived, one-time execution lease to the account, command hash, and policy/configuration hash. The EA must confirm that binding before execution. Missing, expired, consumed, or mismatched bindings fail closed and can be reported as a failed command. Recovery proof is also bound to the command ID and command text so a stale approval cannot be applied to unrelated work.

Failure-mode table

Failure                         Detection/state                 Recovery or final handling
------------------------------  ------------------------------  -------------------------------
Repeated Telegram event         Seen channel/message key        Skip the repeated event
Gap in live Telegram IDs        Cursor and next message ID      Fetch missing range; poll later
Old recovered Telegram message  Recovery age check              Mark seen and log as skipped
Pull or ACK response is lost     Open remains awaiting ACK       Retry same ID after quiet period
EA sees an existing trade ID     Receiver duplicate check        Do not reopen; ACK as duplicate
Broker/terminal rejects order    Negative ACK                    Record failure; remove that ID
Never-pulled command expires     Maximum-age check               Record stale and remove
Pulled command never ACKs        Age plus delivery attempts      Record stale-unacknowledged
Risk lease is stale/mismatched   Binding validation              Reject before execution
Telemetry becomes old           Report timestamp/history         Treat health as unknown; inspect

Practical failure-injection checklist

A delivery system should be tested at failure boundaries, not only with a happy-path sample. A useful checklist is:

1. Submit the same Telegram message twice and confirm the channel/message key prevents a second parse.
2. Simulate missing Telegram message IDs and confirm recovery processes the range in ascending order without replaying the live boundary.
3. Disconnect after an open-command pull but before ACK; confirm no redelivery inside the quiet period and the same command ID after it.
4. Make the receiver find an already-open correlation ID and confirm it reports a duplicate without opening another trade.
5. Return a negative execution result and confirm the log records failure while unrelated queued IDs remain.
6. Age one never-pulled command and one previously delivered command; confirm their stale states remain distinguishable.
7. Schedule a delayed command and confirm freshness is measured from its eligible execution time.
8. Change the account, command hash, or policy hash and confirm an execution lease is rejected.
9. Verify that an account report updates telemetry but does not mark a command as executed.
10. Restart a component between queueing, pulling, and acknowledging; confirm persisted cursors, queues, command IDs, and audit records recover as expected.

What users can validate before connecting an account

Delivery engineering cannot compensate for an ambiguous source message. Use the free Telegram Signal Format Tester to see which symbol, side, entry, stop loss, and targets can be extracted from sample text without connecting Telegram, MetaTrader, or a broker account. Then review the available copier controls, the platform's security practices, and the Trading Risk Disclosure.

Engineering takeaway

Reliable delivery is a chain of explicit states: identify, queue, pull, validate, execute, acknowledge, and record. Stable command IDs make retries traceable; ACKs distinguish receipt from execution; receiver deduplication makes retry safer; age limits stop indefinite replay; and gap recovery repairs missed Telegram events. None of these controls eliminates trading risk, broker risk, configuration mistakes, or outages, but together they make failure visible and recovery testable.