Не приходит полная версия OnTrade

А зачем Вам trans_id в сделке?
-------------------
Поясняю:
Сделка совершается по выставленной заявке. В сделке есть номер заявки,
Номер есть всегда и по нему можно найти эту заявку.
-----------------------------
trans_id - это номер транзакции, по которой уже выставлена заявка.
т е транзакция уже давно исполнена.
Вместо нее есть заявка.
В данном случае и заявка исполнена, вместо нее есть сделка.
Т е  даже заявку нет смысла искать, а уж  trans_id тем более...

Предположу, что он не приходит при выполнении заявки в нескольких сделках, либо в заявках, установленных до за пуска скрипта. Но это лишь предположение.

Версия quik 12.6.0.53. Полностью свой скрипт. Например сделка на покупку одной акции SOFL. Последний раз ошибка была 1-го февраля. За короткий промежуток были совершены три абсолютно идентичные сделки по близкой цене: в 17:01:54, в 17:04:15, и в 17:05:29. Все три на покупку одной акции SOFL. По первой и третьей сделкам пришли три функции OnTrade. По второй сделке только одна. Замечу также, что по первой и третьей сделкам вместе с функциями OnTrade приходили также две функции OnOrder, по второй сделке функция OnOrder пришла только одна. Но в эти функции я не заглядывал, не могу сказать, в чём отличие (если это важно - могу заглянуть, всё сохранено). Каких-либо особых событий, предшествовавших этой ошибке, типа разрыва соединения и т.д., не наблюдалось.  

Тогда вероятнее всего Вы просто теряете сообщения, когда по заявке совершаются несколько сделок относительно быстро.
Если надо принять все то сделайте очередь сообщений.  один из примеров есть в документации на библиотеку QLUA
Другой есть в моей теме на форуме по универсальному обработчику событий

Непонятно. Насколько я знаю, все функции OnTrade приходят в одном потоке, т.е. даже если две сделки совершились строго одновременно, функции по ним вызовутся последовательно, и их невозможно потерять.

Кроме того, в приведённом примере интервал между сделками несколько секунд. Это не быстро. Быстро - это когда десятки сделок в секунду. Я такое видел, и мой скрипт их успешно обрабатывает.  

Если правильно вас понял, то Вы обрабатываете все события внутри колбеков.
Т е Вы тормозите терминал QUIK на время работы вашего скрипта.
Да, в этом случае события вероятно вы не пропустите. Но это лишь предположение,
Судя по установленной Вами задержки,  и в этом случае найдутся способные  написать такой скрипт.

   Не видя вашего кода, сложно что-то сказать, но попробуйте сделать  sleep(50)  и посмотрите что будет.
С задержкой 585000 ваш код в main практически отключен. Это так вами задумано?

Замечу также, что ошибка возникает крайне редко. Я выше писал - 1-2 раза в день, но это было преувеличение. На самом деле вот сегодня она случилась трижды, а до этого в последний раз была 1-го февраля. При том что мой код работает ежедневно и выполняет сотни транзакций в день. Если бы бяка была в моём коде, она бы вылезала чаще.  

Просто разбираюсь с тем же самым, и вот что удалось выяснить не который слой ошибок. Почему роботы закрываются "просто так" и как это фиксят в проп-торговле?
Это класс ошибок, который случается даже с идеально спроектированными системами. И причина всегда одна: > Расхождение между биржевой реальностью и состоянием в QUIK!

Вот конкретные механизмы  (примеры).

1. Главная причина: Асинхронность данных в QUIK. Здесь помним QUIK — это клиент терминал, а не биржа!

Время в QUIK ~= Время на бирже
local q_time =  -- локальное время QUIK
local e_time = -- время биржи (если доступно)
Разница может быть ~ 0.1-5 секунд, а то и более!

Что происходит:
1. Биржа. Цена прошла стоп > стоп сработал;
2. QUIK (через 0.5-2 сек). Получил тик > показал в стакане;
3. Робот. Увидел в стакане > решил "стоп сработал";
4. Но, Стоп уже сработал на бирже, а в QUIK ещё не отобразился.
Результат: робот пытается отменить уже исполненный стоп > получает ошибку!
--------------------------------

2. "Призрачные" стопы в QUIK. QUIK показывает активный стоп.
stop_order = getItem("stop_orders", index)
if stop_order.flags == 1 then
   -- Считаем активным
   -- Но на бирже он мог уже сработать!
end

Это случается при:
* Лаге данных (биржа > шлюз брокера > QUIK);
* Частичном исполнении (часть уже исполнилась, QUIK ещё не обновил qty);
* Ошибках протокола (QUIK не получил подтверждение удаления).
--------------------------------

3. Классический кейс рассинхрона. Таймлайн (реальный):
[00:00.000] Цена Bid = 100 000 (на бирже)
[00:00.100] Цена достигает стопа 100 000
[00:00.150] Биржа исполняет стоп
[00:00.300] QUIK получает обновление стакана
[00:00.350] Робот видит Bid = 100 000 > думает "стоп ещё не сработан"
[00:00.400] Робот пытается изменить стоп > ошибка