Восемь типов обновлений не доходили до ботов

• ~Очередь обновлений сохраняет и читает все пятнадцать видов. Раньше в неё попадали только message, channel_post, callback_query, inline_query, chosen_inline_result, pre_checkout_query и guest_message, а chat_member, my_chat_member, chat_join_request, message_reaction, poll, poll_answer, edited_message и edited_channel_post терялись между сервером и ботом.
• ~Касается и getUpdates, и вебхука: оба берут обновления из одного хранилища, так что смена способа доставки ничего не меняла.

Выглядело это как обновление без содержимого. Сервер честно ставил событие в очередь, счётчик update_id увеличивался, бот получал ответ — и все поля в нём были пустые. Типизированные библиотеки на такое не жалуются: раз ни одно поле не заполнено, ни один обработчик не совпадает, и в логе остаётся только «обновление не обработано».

Поэтому chat_member, my_chat_member и chat_join_request из сборки chatmember до этой сборки ни разу не дошли ни до одного бота, хотя на сервере формировались правильно. То же самое случилось с poll и poll_answer из сборки polls-members.

Восемь типов, которые добавились позже остальных, хранятся как JSON, а не как вложенный документ. Причина простая: в этих обновлениях каждый идентификатор — 64-битное число, а собственный JSON базы пишет такое число как {"$numberLong": "…"}, и обратно оно уже не читается.

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