Один запрос к Telegram завис на 51 минуту и остановил весь конвейер. Соединение установилось через семь минут, сервер оборвал его на середине, а повторное подключение случилось только в конце. Пока воркер ждал, очередь стояла целиком: задачи выполняются последовательно, и один висящий вызов блокирует все остальные.
Что именно произошло
Инцидент начался с обычного запроса к Telegram API. Через семь минут соединение наконец поднялось, но сервер оборвал его на середине передачи. Клиент остался в состоянии ожидания и не пытался переподключиться, реконнект произошёл только спустя 51 минуту. Всё это время воркер был занят зависшим запросом, а очередь задач копилась.
Ключевая деталь: очередь выполняет задачи последовательно. Пока один воркер обрабатывает задачу, остальные ждут. Если задача подвисла на сетевом вызове без таймаута, она блокирует не себя, а весь конвейер. Один такой висяк превращается в простой на час.
Чтобы наглядно представить масштаб: если в минуту через конвейер проходит десять задач, за 51 минуту невыполненными остаются более 500 задач. Часть из них может быть потеряна навсегда, если очередь не имеет персистентного хранения. Один запрос без таймаута способен создать эффект домино: связанные сервисы начинают отправлять ретраи, новые задачи поступают быстрее, чем обрабатываются, и нагрузка на инфраструктуру растёт.
Почему один запрос валит весь конвейер
Сетевые вызовы, это всегда риск. Сервер может не ответить, ответить частично или оборвать соединение на середине. Без ограничения времени клиент будет ждать бесконечно. В большинстве HTTP-клиентов таймаут по умолчанию либо выключен, либо настолько большой, что эквивалентен бесконечности.
В этом случае сработала комбинация двух факторов: отсутствие таймаута на операцию и отсутствие активного реконнекта после обрыва. Соединение установилось через семь минут, но после обрыва клиент не получил ни данных, ни ошибки. Для него запрос остался открытым. Telegram молчал, а воркер продолжал держать в памяти состояние