CustomRatesUpdate + CustomTicksAdd: пропадает M1-история пользовательского символа

Здравствуйте.
Выявлен баг на пользовательских символах.

Изначально я заметил проблему в реальной работе примерно между 00:00 и 03:00 по Москве: локальные сутки уже сменились, а по UTC ещё продолжаются предыдущие.
В этот период после начала поступления новых тиков могла пропадать часть M1-истории.

Позже удалось сделать небольшой воспроизводимый тест, который работает независимо от времени запуска.

Скрипт создаёт два новых custom-symbol с одинаковыми исходными данными:

  • TestRatesUpdate_* — история записывается через CustomRatesUpdate ;
  • TestRatesReplace_* — та же история записывается через CustomRatesReplace .

В оба символа одним вызовом записывается непрерывная M1-история до 12:00 предыдущего календарного дня. После этого через CustomTicksAdd() добавляются три новых тика в 12:01:10 , 12:02:10 и 12:03:10 .

На MT5 build 6230 получен следующий результат:

2026.10.08 21:51:25.672 Terminal build: 6230
2026.10.08 21:51:25.672 UPDATE symbol: TestRatesUpdate_261008_215125
2026.10.08 21:51:25.672 REPLACE symbol: TestRatesReplace_261008_215125
2026.10.08 21:51:25.688 UPDATE: full=1443, bars 00:00..12:00 = 0/721, F = MISSING
2026.10.08 21:51:25.704 REPLACE: full=2164, bars 00:00..12:00 = 721/721, F = PRESENT

То есть после CustomRatesUpdate + CustomTicksAdd исчезает весь диапазон M1 предыдущего календарного дня от 00:00 до 12:00 включительно — 721 бар.

При той же последовательности действий и тех же данных, но с CustomRatesReplace , вся история сохраняется.

Итоговый A/B:

CustomRatesUpdate + CustomTicksAdd -> full=1443, потеря 721 M1

CustomRatesReplace + CustomTicksAdd -> full=2164, история сохранена

Для наглядности искусственные цены образуют линейно возрастающий тренд, поэтому на графике TestRatesUpdate_* потерянный участок виден как явный разрыв, тогда как на TestRatesReplace_* история остаётся непрерывной.


Из-за этого в рабочем коде мне пришлось отказаться от CustomRatesUpdate для такой записи M1 и использовать CustomRatesReplace, что вызвало проблемы с разрастанием исторических данных за текущий год до гигабайтов (об этом создам отдельную тему) .

Я подтверждаю наличие проблемы и сообщил о ней в MetaQuotes.