11 минут назад, Старик сказал:Во-первых, я бы попытался понять с чем связано то, что это подозрение на баг проявляется только на audnzd.
Я не готов к версии, что это баг мт5, который мы в тестах случайно выявили - более вероятно, что что-то не так у нас.
Не хочу подталкивать к возможно ложному пути, но хотелось бы, для начала, попробовать понять есть ли отличия в составе и сопоставимых значениях глобальных переменных для этой пары и, например, пар audcad и eurnzd.
Я понимаю как сложно искать такие мигающие и редко проявляющиеся баги, а если это еще и с сложнейшим рестартом как-то связано, то и думать об этом страшно...
Возможно предположить, что это особенность конвертации системы управления ордерами. В МТ5 используется трех-составная схема "ордер(торговый приказ)-сделка(исполнение приказа) - позиция. В МТ4 односоставная - ордер = позиция (не говорю проотложки). Если наш запрос не находит в списке рыночных ордера, то запрос повторяется для позиции, а вот позиция может уже существовать, но сделка еще не исполнена. В этом случае лотнгость позиции может быть от 0 до лотности ордера.
Теоретически из этой ситуации можно выйти если ТП для ордера определять ДО его передачи на исполнение и затем независиомо ни от чего назначать ему, ранее рассчитанный, ТП.
Другой путь - обнаружив нулевую лотность ответить нулевым ТП. Что вызовет ожидание таймера и пересчет ТП по его истечении.
18 минут назад, Старик сказал:Схожее дерьмо со свопам напостоянку - а с первыми ордерами сеток, может быть, мт5 иногда не понимает лотность первого ордера и стоит её искать в исторически более раннем для мт5 учете позиций по направлению.
Ну если предположить, что это проявление багов мт5 всё же - в мт5 тоже баги есть, куда ж без них...
"Это не баг, это фича!" (с) 
Кстати, косяк со свопами в МТ5 я давно нашел, причина в том же! Берется своп из сделки а не из позиции, у сделки своп появится только после закрытия позиции.
21 минуту назад, Старик сказал:Если я всё/вас правильно понял, это терминальный баг бота для мт5 и он слетает с графика, если втыкается в такую ошибку?!
Тогда такой баг имеет высший приоритет в разработках для мт5 - бот не должен уходить в отказ и слетать с графика ни при каких обстоятельствах.
Другое дело, что версия для мт5 всё же пока является ведомой и, для начала, надо апгрэйдить и верифицировать версии для мт4 и лишь потом разбираться с, как следствие, улучшенными версиями для мт5.
Так что для мт5 это один из багов с наивысшим приоритетом - но его поиск и лечение можно запланировать и отложить на период после апгрейда и верификации соответствующих версий бота для мт4 (и, как следствия, автоматического апгрейда и мт5 версий).
Вполне возможно именно этот (layer_market) отказ отловить и обойти, но логично преполагать, что 0 цена пункта вызовет целую цепочку сходных отказов и вылетов. Это сильно беспокоит. Не факт. что такой же баг не может появиться и в МТ4.
23 минуты назад, Старик сказал:По логике не своевременно концентрироваться на поиске и лечения плавающего бага в одной из версий для мт5 в момент, когда надо выполнить доработку и абсолютно ключевую верификацию версий для мт4.
В любом случае сначала надо добиться сопоставимой работы совместимых версий для мт4 - и лишь потом искать баги и дорабатывать мт5 со своими мт5 приветами.
Трудно не согласиться, но объем рабобты по выявлению причин расхождений зашкаливает. Приходится вносить правки по одной, начиная с "базовой 1.43". При этом, поскольку патч-ноты я не вел, иногда довольно сложно вспонить что и где менялось. Очень много времени отбирает.
Есть мысли, довольно значительно/полностью переделать модули kernel_market и kernel_order.. В любом случае выпускать правки и релизы, не устранив первичное расходжение, мне тоже представляется не оправданным.
-Setkav1.43ADX-IMP-R186-USDCHF-M1-500-500-0_01x3.1-adx-.png.749ef7da5e785d03c6ea026b6a85d976.png)
