#1833 Fix scalper orderbook trades aggregation

[xsevios]

Fixes #1833

Description

Ignore trades which timestamp is higher than upper bound of currrent aggregation range.

Testing

Add test with corresponding trades data

Risk

No major changes

Do you agree with those?

• [] I agree to follow the Contributing guidelines
• [] I agree to follow the terms of the Code of Conduct

[xsevios]

@sbelashevskiy, спасибо за ответ.

Сам итератор принимает параметр orderedTrades, что предполагает корректную опорядоченность сделок.

Действительно, не обратил на это внимание. А где гарантия того, что API присылает сделки по порядку? В документации к Alor OpenAPI не увидел такого. В поддержке мне не ответили, но пользователи API сказали, что порядок может быть нарушен, так как со стороны МосБиржи данные приходят по UDP.

И скорее всего, API присылает сделки в правильном порядке, а нарушается их порядок в рузультате лагов сети или локальной машины т.к. ранее на эту проблему никто не указывал.

Даже если проблема в лагах сети, появление в софте бесконечных циклов не есть хорошо :) Менее подкованные пользователи не смогли бы выявить проблему. Но в чате поддержке я замечал такую же проблему, как у меня: https://t.me/c/1617721897/5949

Более корректный фикс данной проблемы - это применить сортировку по времени перед вызовом итератора (количество сделок не более 1000).

Думал о том, чтобы применять сортировку. Но не будет ли это слишком затратно, если будет открыто 10 стаканов с активными инструментами и на каждый новый принт будет применяться сортировка?

Эти изменения можно оставить, как проверку граничного случая

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

[sbelashevskiy]

@sbelashevskiy, спасибо за ответ.

Сам итератор принимает параметр orderedTrades, что предполагает корректную опорядоченность сделок.

Действительно, не обратил на это внимание. А где гарантия того, что API присылает сделки по порядку? В документации к Alor OpenAPI не увидел такого. В поддержке мне не ответили, но пользователи API сказали, что порядок может быть нарушен, так как со стороны МосБиржи данные приходят по UDP.

И скорее всего, API присылает сделки в правильном порядке, а нарушается их порядок в рузультате лагов сети или локальной машины т.к. ранее на эту проблему никто не указывал.

Даже если проблема в лагах сети, появление в софте бесконечных циклов не есть хорошо :) Менее подкованные пользователи не смогли бы выявить проблему. Но в чате поддержке я замечал такую же проблему, как у меня: https://t.me/c/1617721897/5949

Более корректный фикс данной проблемы - это применить сортировку по времени перед вызовом итератора (количество сделок не более 1000).

Думал о том, чтобы применять сортировку. Но не будет ли это слишком затратно, если будет открыто 10 стаканов с активными инструментами и на каждый новый принт будет применяться сортировка?

Эти изменения можно оставить, как проверку граничного случая

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

По API нет четкой уверенности. Я думаю, что здесь может и API нарушать порядок, хотя я ранее такого не наблюдал. В любом случае раз такой случай возник, то лучше применить сортировку по времени.

Там отсечка стоит на 1000 записей. Для сортировки это не так много. Да и тем более насколько я понимаю это не такой частый случай. Так что в большинстве случаев сортировка будет отрабатывать за O(n). Можно подебагать на ликвидном инструменте сколько по времени будет занимать сортировка. Думаю, не так много.

Да, текущие изменения можно оставить и добавить в стрим для сделок сортировку

[sbelashevskiy]

Описанная проблема будет исправлена в https://github.com/alor-broker/Astras-Trading-UI/pull/1846. Сортировки должно быть достаточно, чтобы решить проблему. При этом отладка показывает, что операция сортровки не оказывает существенное замедление на операцию отрисовки сделок (0-1 мс)