Report: точное время исполнения в миллисекундах и связь с ордером

[kirillDevPro]

Проблема

MoonTerminal не может надёжно поставить метки входа/выхода закрытой сделки на миллисекундной оси графика. В исследованной реплике отчётов BuyDate, SellSetDate, CloseDate приходят как целые секунды. После преобразования в миллисекунды получается начало секунды (…54.000), и на резком движении стрелка может оказаться перед падением, хотя цена исполнения относится уже к нижнему участку.

Исследованная версия SDK: 2e67562f (пин MoonTerminal). Это запрос на проверку и расширение контракта MoonBot → MoonProto → клиент; обрезание миллисекунд самим SDK не доказано.

Воспроизводимый пример

SAGAUSDT, 2026-09-11:

• Лонг: BuyDate = 1789128594 (12:09:54 UTC), средняя цена входа 0.01565989.
• Следом отдельный шорт: BuyDate = 1789128595, цена 0.01567.
• На секундном масштабе зелёная метка лонга оказывается слева от резкого падения.
• Сопоставление с публичными тиками по точной цене не решает проблему: средняя цена нескольких исполнений может не существовать среди отдельных тиков. Подбирать ближайший тик — это оценка, а не время конкретного исполнения.

В логе лонга есть строка Buy order DONE! FILL: 100% Opened: 12:09:54.846. Однако Opened нельзя автоматически объявлять временем исполнения: в этом примере ответ размещения ордера с status: NEW тоже содержит updateTime = 1789128594846. Время размещения, получения лога и фактического исполнения необходимо различать.

Ограничение связи отчёта с ордером

SDK предоставляет временные поля отдельных legs (create_time(), close_time()) и Order.uid, но в исследованной публичной модели нет документированной однозначной связи с записью отчёта. ReportUID — самостоятельный идентификатор строки отчёта, его нельзя считать равным Order.uid. newRecID также не является UID ордера. В примере ExOrderID отчёта содержит строковый идентификатор выходной заявки, тогда как публичный ExchangeOrder предоставляет числовой int_id.

Даже если клиент видел live-ордер, он должен уметь связать точное время с нужной строкой отчёта без эвристики по цене/секунде; после перезапуска и для исторических сделок live-состояния может уже не быть.

Предлагаемый контракт

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

Просьба документировать:

• Единицы и временную систему: предпочтительно Unix UTC milliseconds; если часы ядра — явно описать преобразование и исключить двойную коррекцию.
• Семантику частичных исполнений: первое/последнее исполнение или иной выбранный момент. Средняя цена не определяет единственный момент исполнения.
• Отсутствующее точное время как отсутствие значения, а не выдуманные .000.
• Семантику отменённого остатка: время закрытия/отмены leg не должно автоматически считаться временем последнего fill.
• Совместимость со старыми ядрами/схемами без изменения смысла существующих секундных колонок.

Если точное время будет доступно через отдельный поток/запрос, нужен стабильный документированный ключ связи с записью отчёта, включая историю после перезапуска. Одной связи только с текущими live-ордерами недостаточно.

Ожидаемая проверка

1. Сделка из нескольких fills со средней ценой между уровнями получает метку по документированному времени исполнения без поиска совпадающего публичного тика.
2. Лонг и шорт одной монеты, а также несколько сделок в одну секунду не смешиваются; учитывается область уникальности идентификаторов между ядрами.
3. Время и связь сохраняются при обновлении строки отчёта, переподключении и повторной загрузке истории.
4. Старые записи без точного времени читаются как прежде и не выдаются за миллисекундно точные.
5. Отмена неисполненного остатка не сдвигает метку на время отмены без явно описанной семантики.

Связанный контекст в терминале: Moonbot-Tech/MoonTerminal#497 — оценка по публичным тикам исправила часть случаев, но не заменяет точные данные исполнения для усреднённых цен.