Еще одна логическая ошибка Strategy.ApplyMonitorRules

Еще одна логическая ошибка Strategy.ApplyMonitorRules
Atom
25.03.2017
RomSunZ


Если заявка уже исполнена, но сделка стратегией еще не получена, то при остановке стратегии с отменой активных заявок получаем ошибку
Цитата:
Заявка хххххххх (0xхххххх) не была отменена по причине System.InvalidOperationException: Ошибка снятия заявки ххххххх. Текст 'Вы не можете снять данную заявку'..

В этом случае код:
Код

            var canFinish = false;

            order
                .WhenCancelFailed(Connector)
                .Do(() =>
                {
                    if (ProcessState != ProcessStates.Stopping)
                        return;

                    canFinish = true;
                    this.AddInfoLog(LocalizedStrings.Str1387Params.Put(order.GetTraceId()));
                })
                .Until(() => canFinish)
                .Apply(this)
                .Exclusive(successRule);

приводит к тому, что стратегия останавливается раньше, чем получит сделки по такой заявке. Нужна дополнительная проверка статуса такой заявки и в случае, если баланс отличается от объема ожидать сделки, и только после этого останавливать стратегию.



Спасибо:


Slepoy

Фотография
Дата: 25.03.2017
Ответить


Так вроде для этого есть спец свойство - "Strategy.WaitAllTrades - останавливать стратегию только после получения всех сделок по зарегистрированным заявкам.". Я правда им не пользовался ни разу, так что на счёт его работоспособности я не в курсах.
Спасибо:

RomSunZ

Фотография
Дата: 26.03.2017
Ответить


Оно в данном случае не сработает, т.к. вызывается правило WhenCancelFailed
Спасибо:

Slepoy

Фотография
Дата: 26.03.2017
Ответить


Ну тогда "это прискорбно" (с) Бородач. [laugh]

Я вообще всё больше и больше прихожу к мысли, что из всего арсенала СтокШарп, надо оставить лишь коннекторы, а всё остальное переписывать под себя: правила, методы и т.п. Брать их варианты за основу и оптимизировать под себя. Это даст нам, как пользователям, уйму преимуществ: так мы будем максимально полно понимать логику кода, и не зависить от их хотелок/перехотелок, когда они при каждом новом релизе API чего-то там перепиливают руководствуясь вообще не известно чем. Фактически, сейчас при каждом новом релизе - мы очень рискуем получить нежданчик в работе бота о котором даже не подозреваем, и как на зло проявится нежданчик не на этапе компиляции проекта, а именно в процессе реальной работы. Они сделали из СтокШарпа огромного монстра, змей-горыныча и теперь сами за ним не поспевают. Библиотека слишком разрослась. Стало слишком много элементов. Она стала слишком избыточна. Некоторые "функции" дублируются 3...4 методами! Вот зачем это нужно? Нахрена мне 4 метода, которые все делают одно и тоже? Они наивно полагают, что чем больше тем лучше, типа больше возможностей, больше функционал и т.п. Ага, ага, пусть и дальше живут в своих иллюзиях. Вот робописателю они нафиг не нужны. Нужен всего один метод, всё просто как топор. Зачем ему изучать работу 4х методов? Выбирать между ними, какой лучше выбрать, ломать голову, изучать их логику, тратить время. Он потратит день времени, а потом в исходниках узнает, что они все просто дубли ))). Разработчики не только усложнили жизнь клиентов - сделали сложным и долгим процесс обучения и роботонаписания, но и себе поднакосячили изрядно. Они же и себе жизнь испортили, ибо создав монстра, этого змея-горыныча, они не только тратят на его обслуживание времени в 3-4 раза больше, чем следует, но и самое главное - они ещё утратили над ним полный контроль. Они его сделали настролько большим, избыточными и взаимосвязанным, что любое малое изменение в одной части кода, по принципу домино ведёт к измененению в других частях, но каких - они отследить уже не могут ))). Связей и ветвлений настолько много, что они не могут всё отследить ))). Поэтому они постоянно косячат и правят баги. По истории с ГитХаба - прекрасно прослеживается вся картина багфиксинга. И они никогда не победят баги, ибо из-за избыточности кода, из-за его сложности, из-за кучи взаимосвязей они не могут увидеть всей картины. Они создали змея-горыныча, как только они отрубают одну голову, т.е. правят баг, либо вносят новшество, то тут же вырастает три новых головы и так до бесконечности. И ничего поделать нельзя. Ждать от них чуда - не стоит, они не понимают, что их избыточность и сложность никому не нужна, даже им самим. Надо брать всё в свои руки, оставить лишь одни коннекторы, а всё остальное, по мере использования, потихоньку переписывать под себя. Надо выпиливать всю избыточность, все дубли, выпиливать их закрытые "ecng" и писать нормальный понятный код.
Спасибо:

RomSunZ

Фотография
Дата: 22.04.2017
Ответить


Есть два варианта решения проблемы.
1. Изменить правило срабатывания WhenCancelFailed с проверкой order.State != OrderStates.Done. В плюсах - не надо изменять класс Strategy, т.к. в указанном выше варианте просто не будет срабатывать WhenCancelFailed. В минусах, событие System.InvalidOperationException: Ошибка снятия заявки хххх не вызывает WhenCancelFailed в принципе в данном случае (что логично, с другой стороны, т.к. заявка то уже исполнена).
2. Добавить в логику обработки ApplyMonitorRules.WhenCancelFailed дополнительную проверку на order.State == OrderStates.Done. В минусах - дополнительный код, с хитровые...ной логикой обработки, в плюсах - больше ничего не меняется в логике АПИ.

У кого какие мысли?
Спасибо:


Добавить файлы через драг-н-дроп, , или вставить из буфера обмена.

loading
clippy