Не приходит полная версия 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] Робот пытается изменить стоп > ошибка

Я использую только класс TQBR, стандартную торговлю акциями, если вы об этом спрашивали. В таблице сделок да, trans_id есть. Но возможно именно у тех сделок, о которых речь, не было. Не проверял, в следующий раз как случится - посмотрю.  

User12501, Скажите на русском читаете, если нет, то какие слова Вам не понятны

Более-менее все слова понятны, только непонятно, как они связаны с моим вопросом.  

И все таки:

User12501,
Покажите как Вы реализовали ОnTrade.  
Возможно будет понятнее причина.

По-моему мнению причина в том, что trans_id -  это идентификатор транзакции.
Главное в этой фразе что это ТРАНЗАКЦИЯ.
И это транзакция  на выставление заявки.  Т е это не id заявки и не id сделки.
Поэтому вполне допускаю, что сервер QUIK не посылает повторно сообщение о сделке, если все параметры сделки уже переданы.  
Нет смыла тратить время на передачу id.
Возможно это происходит если сделки совершаются с малым интервалом.
Тогда второе сообщение по первой сделки просто затирается сообщением по второй.  
Но в любом случае отслеживать id транзакции в сообщениях по сделке это нонсенс.
 

Вот с этого и надо было начинать.
Какой ACTION указан у транзакции, сделки по которым без trans_id?

Но вы так-то тоже обрабатываете "сырые" колбэки и получаете соответствующие проблемы, которые потом закрываете "костылями".

Я использую такой же подход. Тем более что сканировать таблицы необходимо в любом случае при старте скрипта.

Правда такой подход уже сложнее реализовывать, если данные гоняются через socket в алгоритмы, написанные не на lua. Необходимо реализовывать свой колбек на стороне socket сервера, организованного также через сравнение числа записей. А также колбеки по изменению данных в записи таблицы, например, флага состояния или баланса.

   У меня есть простая функциональность создания собственных событий в виде таблиц событий, в которые записываются функции с их параметрами при подписке на событие.  Если надо, то при наступлении в скрипте события, например, появления каких то данных выполняется запуск всех функций таблицы соответствующей такому событию.

1.   Кто вас заставляет ждать 120 сек.? Ждите 1 млс.  И, вообще, возитесь с коллбеками сколько хотите . Для вас чем сложнее, тем лучше.

2.   Я знаю как делать сложные системы не теоретически. И один из основных принципов их создания это не делать лишних движений. Несделанное, во-первых, не ломается, а во вторых, супер эффективно, так как не требует ресурсов.
  С тем подходом к созданию роботов, который использует Nikolay и я не видно проблем создания сложных роботов.
  Кстати, хотя я стараюсь находить и использовать простые решения, робот у меня не сильно простой. Во всяком случае он полностью автономный. Я, конечно, смотрю что он делает, но уже давно он работает месяцами без моего вмешательства.

  1. Читайте:
  2. Вы проверяли задержку между коллбэком с заполненными параметрами и появлением записи в таблице? Если нет, то проверьте.

   1. Я OnQuote не пользуюсь. QUIK не предназначен для высокочастотной торговли. Из стакана вам приходит история с задержкой как минимум 2-3 сек. и ваша реакция, скорее всего, тоже > 2 сек. Хотелось увидеть реальные доходные стратегии в таких условиях.
   2. Если мне нужны какие то данные из текущей таблицы торгов, то я их читаю в цикле, с нужным мне периодом (у меня есть возможность создавать такие циклы, кроме основного) и фильтрую, чтобы не было повторов, по параметру VOLTODAY. Получается не хуже по результату и эффективности использования ПК, чем при использовании OnParam.

   Зачем вы используете, не первый раз громкие понятия. от которых, похоже, очень далеки? Вы сделали в математике открытие: "доказать на реальной торговле" . Вам это надо опубликовать в научном журнале.

TGB, А какие слова для Вас не понятны? Повторюсь, безопасность счёта можно доказать математически, событийная модель с инвариантами и реконсиляцией — единственный известный путь.