Jak bot wysyła zlecenie w MT5 i co odpowiada serwer - kody zwrotne po ludzku

W skrócie: bot nie otwiera pozycji sam. Składa prośbę (symbol, kierunek, lot, SL, TP), wysyła ją do serwera brokera i dostaje odpowiedź z kodem. Kod “wykonano” to jedyny dowód, że pozycja jest. Resztę kodów dzielę na dwie grupy: takie, na które trzeba poczekać, i takie, które wymagają zmiany prośby.

Prośba i odpowiedź

Każda operacja bota to ten sam schemat: wypełnia strukturę z polami (rodzaj operacji, symbol, lot, cena, SL, TP, typ wypełnienia, komentarz, numer magic) i wywołuje wysyłkę. Wywołanie zwraca tylko informację, czy prośba w ogóle poszła do serwera. Co serwer o niej sądzi, mówi dopiero osobna struktura wyniku z kodem zwrotnym. Bot, który sprawdza tylko pierwszą rzecz, uważa, że otworzył pozycję, a serwer w tym czasie ją odrzucił.

Dlatego w logu każdej poważnej operacji chcę widzieć trzy rzeczy: co bot wysłał, jaki kod wrócił i jaki był bieżący kurs. Bez tego rozmowa o “dziwnym zachowaniu” kończy się zgadywaniem.

Kody, które widuję najczęściej

Kod	Znaczenie	Co zrobić
10009	zlecenie wykonane	nic, to sukces
10004	requote, cena się zmieniła	ponowić z nową ceną
10015	zła cena	poprawić cenę zlecenia
10016	złe poziomy SL/TP	poprawić SL/TP (za blisko ceny)
10018	rynek zamknięty	czekać na sesję
10019	brak środków	zmniejszyć lot, sprawdzić margin
10021	brak cen	czekać na tik
10030	nieobsługiwany typ wypełnienia	zmienić typ wypełnienia

Numery pochodzą z dokumentacji MQL5. W logu terminala te same odpowiedzi widać jako tekst w nawiasach kwadratowych, np. “No prices” albo “Invalid stops”.

Czekać czy poprawiać

Odpowiedzi o stanie rynku (rynek zamknięty, brak cen, requote) mijają same. Prośba była dobra, świat nie był gotowy. Tu rozsądnie jest zaczekać do następnego tiku i spróbować raz jeszcze, bez pętli co milisekundę.

Odpowiedzi o samej prośbie (złe stopy, zła cena, za duży lot, zły typ wypełnienia) nie miną. Ponowienie tej samej prośby da ten sam kod, więc bot, który ją powtarza, tylko śmieci w logu i obciąża serwer. Takie odpowiedzi to sygnał do poprawki w kodzie albo w ustawieniach. O limitach liczby próśb piszę osobno w artykule o spamie zleceń.

Przypadek: ponad 30 minut bez cen na złocie

Na koncie jednej z prop firm złoto na realu przez około 34 minut nie dostawało kwotowań. Połączenie działało, pozycje były zsynchronizowane, ale każda zmiana SL kończyła się odpowiedzią “No prices” (czternaście prób w ciągu kilkunastu minut). Restart terminala i ponowne logowanie nie pomogły, bo winny był kanał danych po stronie brokera. Pozycje cały czas miały stary SL, więc ochrona była, tylko bez podciągnięcia. Wniosek dla kodu: przy tym kodzie nie ponawiam w kółko, tylko czekam na nowy tik, bo dopiero on oznacza, że cena wróciła (bot 2010_GoldAsiaEmaChannelBreakoutEA nie miał wtedy pozycji, więc incydent go nie dotknął).

Czego bot nie może założyć

Że “wysłane” znaczy “wykonane”. Liczy się kod z serwera.
Że cena z chwili decyzji jest ceną z chwili wykonania. Rynek poruszył się w tym czasie.
Że ten sam symbol przyjmie te same typy wypełnienia u każdego brokera.
Że odmowa jest błędem bota. Często to normalna odpowiedź na stan rynku.

Checklista

Czy bot sprawdza kod zwrotny serwera, a nie tylko wynik wywołania wysyłki?
Czy w logu jest kod, tekst odpowiedzi i kurs z chwili próby?
Czy odpowiedzi o stanie rynku powodują czekanie na tik, a nie pętlę ponowień?
Czy odpowiedzi o samej prośbie nie są ponawiane bez zmiany?
Czy po “brak środków” bot nie próbuje wejść co tik?
Czy po serii odmów bot blokuje handel i zgłasza alarm?

Powiązane

Źródła

Dokumentacja MQL5, “Trade Server Return Codes” i “OrderSend”, docs.mql5.com (sprawdzone 15.11.2026).

Ostrzeżenie: artykuł ma charakter edukacyjny i nie jest poradą inwestycyjną. Wyniki z przeszłości nie gwarantują przyszłych. Handel na rynkach finansowych wiąże się z ryzykiem utraty kapitału.