Автоматизація Telegram з Telegram Expert: що робити, якщо завдання зупинилося на середині

Коли Telegram-завдання обробляє кілька тисяч записів, збій рідко виглядає як одна зрозуміла проблема. Частина запитів може впертися в обмеження Telegram, частина втратити з'єднання, а частина завершитися помилкою через налаштування конкретного чату або користувача.

Найчастіша помилка в такій ситуації полягає не в самому збої, а в однаковій реакції на різні причини. Якщо після будь-якої помилки змінювати проксі та запускати дію заново, тимчасове мережеве порушення справді може зникнути. Але FLOOD_WAIT від цього не закінчиться, заборона на відправлення повідомлень не зміниться, а втрачена відповідь після вже виконаної дії може призвести до повторної операції.

Тому в масовій автоматизації спочатку визначають причину збою, а вже потім обирають дію: повторити запит, змінити маршрут, почекати або завершити обробку запису.

Зміст

1. 1. Чому одна помилка в Telegram може вимагати чотирьох різних реакцій

2. 2. Коли Telegram-завдання варто повторити через той же проксі

3. 3. Коли проблема справді вимагає зміни проксі

4. 4. Чому FLOOD_WAIT потрібно перечекати, а не обходити повтором

5. 5. Чому timeout не можна автоматично вважати невдалою операцією

6. 6. Як налаштувати retry для масової обробки в Telegram Expert

7. 7. Що зберігати в базі після кожної спроби

8. 8. Як розділити роботу проксі та Telegram Expert

9. 9. FAQ по збоях Telegram-автоматизації
   

Чому одна помилка в Telegram може вимагати чотирьох різних реакцій

На рівні завдання результат часто виглядає однаково: запис не оброблено. Але причина може знаходитися в різних шарах.

Telegram розділяє RPC-помилки за змістом. Одні говорять про некоректний запит, інші пов'язані з авторизацією або правами, треті повідомляють про тимчасове обмеження, а окремий клас стосується внутрішніх помилок сервера.

Для масової автоматизації достатньо розділити їх на кілька груп.

Це базова стратегія, а не універсальна таблиця для всіх методів Telegram. Конкретний метод може повертати додаткові помилки.

Головний принцип простий: повтор має сенс тільки тоді, коли повторне виконання справді може дати інший результат.

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

Такий підхід особливо важливий для завдань, де одна база містить тисячі користувачів, чатів або інших об'єктів. Помилка одного запису не повинна зупиняти весь процес, але й нескінченно повертати цей запис у роботу теж не можна.

Коли Telegram-завдання варто повторити через той же проксі

Повтор через той же маршрут підходить для тимчасової помилки з'єднання або короткочасного серверного збою.

Наприклад, Telegram може повернути внутрішню помилку класу 500. Вона сама по собі не доводить, що проблема знаходиться в проксі. У цьому випадку зміна маршруту може нічого не дати, а обмежений повтор з паузою має сенс.

Не варто відправляти один і той же запит кілька разів підряд. Якщо причина проблеми ще не усунена, повторні запити тільки збільшать навантаження.

Практична схема виглядає так:

• - перша помилка фіксується в логі;

• - завдання отримує коротку паузу;

• - виконується друга спроба;

• - при повторному збої збільшується інтервал;

• - після встановленого числа спроб запис переводиться в окремий стан.
  

Для таких завдань використовують експоненційну затримку. Інтервал між спробами поступово збільшується. Випадкова затримка додає невеликий розкид за часом, щоб кілька паралельних процесів не повторювали запит одночасно. 

Важливо обмежувати кількість спроб. Якщо нескінченно повторювати запити після кожної помилки, тимчасовий збій врешті-решт може перетворитися на постійне навантаження на систему.

Коли проблема справді вимагає зміни проксі

Зміна проксі має сенс тоді, коли є підстави вважати причиною саме мережевий маршрут.

Якщо з'єднання не встановлюється, регулярно обривається або один маршрут дає помилки, повтор через нього може тільки відтворити проблему. Наприклад, ConnectionError - помилка з'єднання, при якій рекомендується перевірити проксі.

Але зміна проксі не є універсальною реакцією на помилки Telegram.

Наприклад, CHAT_WRITE_FORBIDDEN означає, що поточному акаунту заборонено відправляти повідомлення в чат. Інший IP не змінить права акаунта. USER_PRIVACY_RESTRICTED пов'язаний з налаштуваннями користувача і також не вирішується зміною маршруту.

Тому відновлення мережевого з'єднання краще відокремлювати від обробки результату Telegram.

У великих завданнях не варто прив'язувати всю логіку до ручної заміни IP. Потрібно відокремлювати повторні запити від керування проблемними проксі та використовувати поступове збільшення інтервалу між спробами, випадкову затримку та механізм відключення повторних запитів при масових помилках. Такий підхід особливо корисний на мережевому рівні.

Якщо потрібен окремий проксі-шар для таких сценаріїв, можна використовувати SotaProxy: сервіс пропонує резидентські, мобільні, ISP та дата-центр проксі, підтримує ротацію та sticky-сесії, тому можна підібрати маршрут під стабільну сесію або масову автоматизацію. 

Чому FLOOD_WAIT потрібно перечекати, а не обходити повтором

У FLOOD_WAIT_X є принципова відмінність від мережевого збою. Telegram прямо повідомляє, скільки часу потрібно почекати перед повторенням дії. У документації Telegram цей механізм описаний як обмеження частоти запитів.

Тому Telegram не рекомендує автоматично змінювати проксі та повторювати запит після отримання FLOOD_WAIT. Сам факт зміни IP не скасовує серверне очікування.

Те ж стосується SLOWMODE_WAIT_X. Це обмеження, встановлене для конкретного чату. Зміна мережевого маршруту не змінює slow mode.

Тут правильніше зберегти час очікування та повернути завдання в чергу після його закінчення.

Виходить інша модель обробки:

1. 1. Telegram повідомляє час очікування.

2. 2. Система зберігає це значення.

3. 3. Запис тимчасово виключається з активної обробки.

4. 4. Після закінчення очікування завдання повертається в чергу.

5. 5. Якщо повтор знову призводить до обмеження, система враховує нову відповідь Telegram.

Такий підхід кращий, ніж локально вигадувати затримки на кшталт почекати п'ять секунд. Для серверних обмежень пріоритет має інформація, яку повернув сам сервіс.

Чому timeout не можна автоматично вважати невдалою операцією

Найскладніша ситуація виникає, коли клієнт не отримав відповідь.

При звичайній помилці причина часто зрозуміла. При timeout відомо тільки те, що клієнт не отримав очікуваний результат за заданий час. Це не доводить, що Telegram не обробив запит.

Telegram окремо документує цей сценарій для відправлення повідомлень. Запит може успішно створити повідомлення, але відповідь методу втратиться. В результаті клієнт вважає операцію невдалою, хоча дія вже відбулася. Для цього Telegram використовує random_id та updateMessageID, які дозволяють пов'язати вихідний виклик зі створеним повідомленням.

Сервер також використовує random_id для дедуплікації. Якщо той самий ідентифікатор вже застосовувався для відповідного виклику, Telegram не повинен створювати друге таке саме повідомлення.

Після timeout спочатку потрібно визначити, чи могла дія вже виконатися. Тільки після цього обирається безпечний сценарій повтору.

Це особливо важливо для операцій, які створюють побічний ефект. Повтор перевірки зазвичай безпечніший, ніж повтор відправлення повідомлення. Тому retry-політика повинна враховувати не лише тип помилки, але й саму операцію.

Як налаштувати повтор для масової обробки в Telegram Expert

Коли завдання складається з тисяч записів, одного загального правила для всього процесу недостатньо. У кожного запису має бути зрозумілий стан і зрозуміла реакція на помилку.

Умовно можна розбити це на етапи.

1. Спочатку класифікувати помилку

Мінімального набору достатньо:

• - помилка з'єднання;

• - тимчасове обмеження Telegram;

• - заборона або privacy restriction;

• - некоректні дані;

• - внутрішня помилка;

• - невідомий результат після timeout.
  

  

2. Для кожного класу визначити дію

Наприклад:

1. 1. ConnectionError → обмежений повтор → зміна маршруту при необхідності → зупинка

2. 2. FLOOD_WAIT → очікування → повтор після вказаного часу

3. 3. Privacy / Forbidden → завершення запису

4. 4. Invalid data → виправлення даних

5. 5. 500 → повторна спроба зі збільшенням інтервалу очікування

Такий підхід не вимагає вручну прописувати окрему стратегію для кожної помилки.

3. Обмежити кількість спроб

Кількість повторів має бути скінченною. Якщо один маршрут або один запис продовжує падати, завдання має вийти з циклу і отримати зрозумілий підсумковий статус.

Для повторюваних мережевих проблем можна тимчасово припинити повторні запити. Його завдання не в тому, щоб виправити помилку, а в тому, щоб тимчасово припинити звернення до проблемного напрямку і не розмножувати один збій на весь процес. 

4. Зберігати стан кожного запису

В Telegram Expert база розділяє стани Ready, Taken і Done. Ready означає, що запис готовий до обробки, Taken показує, що він вже взятий в роботу, а Done фіксує завершену дію.

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

База дозволяє продовжувати обробку з потрібного стану. При необхідності статус запису можна змінити вручну, наприклад повернути Done в Ready, щоб запустити його повторно.

Крім того, якщо виникла помилка, в логах це також буде відмічено, що дозволить зрозуміти, яку дію вжити.

5. Відокремити повтори від ручної перевірки

Після кількох невдалих спроб запис має потрапити або в кінцевий стан, або в чергу на ручну перевірку.

Якщо Telegram повідомляє, що дія заборонена налаштуваннями користувача, повторювати її автоматично не потрібно. Якщо проблема в з'єднанні, запис можна повернути в обробку після відновлення маршруту.

Так з'являється керований процес, а не нескінченний цикл повторів.

Що зберігати в базі після кожної спроби

При масовій автоматизації сама помилка рідко допомагає розібратися в тому, що сталося. Потрібен контекст.

Для кожної спроби корисно зберігати:
- час;

• - акаунт;

• - виконувану дію;

• - цільовий об'єкт;

• - ідентифікатор проксі або маршруту;

• - номер спроби;

• - тривалість запиту;

• - помилку Telegram;

• - факт зміни проксі;

• - підсумкову дію: retry, wait, skip, stop або review.

Після цього запис «47 помилок» перетворюється на нормальну діагностику.

Наприклад, можна побачити, що всі 47 помилок є ConnectionError і відбуваються через один маршрут. Це проблема мережевого шару.

Якщо всі 47 записів отримали FLOOD_WAIT, причина вже в обмеженнях Telegram.

Якщо 47 користувачів отримали USER_PRIVACY_RESTRICTED, проблема відноситься до умов конкретних операцій, а не до проксі.

Telegram Expert якраз працює з результатами операцій через бази і статуси, а для різних дій формує власні бази результатів. Це дозволяє не змішувати успішно оброблені записи з тими, які вимагають повторної роботи.

Як розділити роботу проксі та Telegram Expert

Проксі відповідає за мережеве з'єднання. Тут перевіряються доступність маршруту, з'єднання, затримки і повторювані мережеві збої.

Telegram Expert відповідає за прикладну частину. Тут визначається, який акаунт виконує дію, який запис знаходиться в роботі, яку відповідь повернув Telegram і що робити з цим записом далі.

Такий поділ не дає перетворювати будь-яку помилку Telegram на проблему проксі.

Для користувача це особливо помітно на масових завданнях. Якщо один запис отримав ConnectionError, можна повторити його після перевірки маршруту. Якщо інший отримав ChatWriteForbiddenError, його немає сенсу відправляти через новий IP. Якщо третій отримав FLOOD_WAIT, йому потрібно призначити очікування.

Telegram Soft Expert вже використовує окремі статуси для таких результатів і зберігає робочий стан записів. Це дозволяє будувати обробку не навколо одного загального прапора «помилка», а навколо результату кожної конкретної операції.

Сам Telegram Expert вирішує набагато ширше коло завдань, пов'язаних з акаунтами, сесіями, базами і масовими операціями.

В ньому можна окремо працювати з реєстрацією та прогрівом акаунтів, керувати акаунтами та їх станами, перевіряти і розподіляти проксі, збирати аудиторії, запрошувати користувачів, відправляти повідомлення і публікувати контент.

Основні можливості Telegram Expert охоплюють весь робочий цикл з акаунтами:

1. 1. Панель акаунтів. Централізоване управління акаунтами, групування, статуси, масова перевірка і масові дії.

2. 2. Авто-реєстрація. Генератор параметрів, ручна реєстрація, реєстрація через SMS-сервіси і універсальний реєстратор.

3. 3. Збір аудиторії. Глобальний пошук, збір користувачів з чатів, коментарів і з акаунтів, перевірка посилань і робота з базами парсингу.

4. 4. Інвайт. Запрошення користувачів за username і ID, а також інструменти інвайту через адміністраторів і ботів.

5. 5. Відправлення повідомлень. Масові розсилки, відправлення за ID і контактами, робота з відкритими діалогами, автопостинг, автовідповідач, коментарі та нейрокоментування.

6. 6. Номери телефонів та контакти. Перевірка номерів у Telegram, робота з телефонними базами, додавання та видалення контактів, експорт контактів, розсилки та інвайт за контактною книгою.

7. 7. Stories. Публікація, коментування, експорт посилань та видалення сторіс з акаунтів.

8. 8. Звіти та бази. Генерація звітів, об'єднання баз та підрахунок результатів розсилок та інвайтів.

9. 9. Спеціальні модулі. Дублікатор сесій, конвертер Session та TData, тіньові сесії, бустер акаунтів, пересильник, клонери чатів та каналів, перехоплювач контенту та інструменти управління адміністраторами.

10. 10. Проксі. Додавання та перевірка проксі, а також чекер пулу проксі з перевіркою перетинів IP-адрес.
    
    

    

    
    

    

    
    

    

    
    

    

    
    
    Тому Telegram Soft Expert не можна розглядати лише як інструмент для роботи з проксі. Проксі відповідають за підключення, а програма управляє самим робочим процесом: акаунтами, їх станами, базами, аудиторіями, комунікацією та результатами окремих операцій.
    

    FAQ щодо збоїв Telegram-автоматизації
    

    Чи потрібно міняти проксі після FLOOD_WAIT?

    Сам FLOOD_WAIT_X повідомляє про необхідність дочекатися зазначеного часу перед повторенням дії. Документація Telegram не описує зміну IP як спосіб скасування цього очікування.

    
    Чи можна повторювати CHAT_WRITE_FORBIDDEN?

    Автоматичний повтор тієї ж дії не вирішить проблему. Помилка означає, що поточний акаунт не може відправити повідомлення в цей чат. Потрібно змінити умови операції або виключити запис.
    

    Що робити після timeout?

    Спочатку визначити, чи могла дія вже виконатися. Для відправки повідомлень Telegram передбачає механізм зіставлення операції та результату через random_id та updateMessageID, тому втрачена відповідь не завжди означає неуспішне відправлення.
    

    Скільки разів повторювати запит?

    У Telegram немає універсального числа retry для всіх методів. Кількість спроб залежить від типу операції та помилки. Для тимчасових збоїв потрібні обмежені повтори зі збільшенням інтервалу, а для кінцевих помилок повтор не потрібен.
    

    Коли дійсно потрібен новий проксі?

    Коли є ознаки проблеми з'єднання або конкретного маршруту. Помилки прав, privacy, некоректних даних та серверних обмежень не стають мережевими проблемами лише тому, що операція виконується через проксі.

    
    

    Правильна retry-політика починається не з кількості проксі та не з числа повторів. Вона починається з класифікації помилки. Якщо Telegram тимчасово обмежив дію, завдання має чекати. Якщо проблема в маршруті, можна змінити проксі. Якщо дія заборонена, запис потрібно завершити. Якщо клієнт не отримав відповідь після операції, спочатку потрібно виключити вже виконану дію.

    
    

    Telegram Soft Expert корисний саме на наступному рівні. При великій кількості акаунтів та записів такі стани потрібно не тримати в голові, а фіксувати в базах, статусах та результатах обробки. Тоді збій окремої операції залишається окремою операцією, а не перетворюється на повторний запуск всього завдання.