Комментарии 8
Я правильно понял, что все будет работать ровно до того момента, пока вам не отрежут туннель?
Я конечно понимаю что это MVP, но в текущее время для хоть какой-то гарантии стабильной работы серверов "вне" должно быть несколько, туннелей к этим серверам должно быть несколько с разными протоколами, хотя бы один из этих серверов должен быть в "дружественной" стране ... настроить маршрутизацию между этим всем и не сойти с ума.
Не скучаешь, опять за старое взялся!
Интересно, как в mimir-tg устроено восстановление после падения посреди опроса каналов. Вы забираете посты каждые пять минут и сразу пишете их через asyncpg. Если соединение с PostgreSQL оборвётся после записи половины пачки, следующий проход должен подобрать оставшиеся и не продублировать уже сохранённые. Я бы использовал уникальную пару (channel_id, message_id) и контрольную точку только после успешной записи. У вас курсор чтения хранится в базе или восстанавливается из последних сообщений?
Всё сделано ровно так, как вы описываете: уникальный индекс на (channel_id, external_id), где external_id это "{chat_id}_{msg_id}", и ON CONFLICT DO NOTHING. Каждое сообщение пишется своей транзакцией вместе с начальным снапшотом метрик, так что обрыв посреди пачки теряет максимум одно сообщение в полёте, а повторное чтение безопасно.
Да, может действительно упасть, но честно говоря, мы пока не чиним — и вот почему. Данные тут не критичные: это пул постов-кандидатов, из которых скоринг выбирает, о чём написать черновик. Потерять несколько свежих постов из одного канала означает, что в этот цикл их просто не рассмотрели как кандидатов. Неприятно, но на работу сервиса не влияет и ничего необратимого с пользовательскими данными не происходит. Срабатывает дыра только при падении или рестарте посреди обхода, то есть редко. Так что знаем, держим в голове, но в очередь на исправление пока не ставили.
Ну и ни разу еще не случалось...

Как я строил ИИ-стартап, или Новые архитектурные риски 2026