Ретраи: сколько раз и с каким интервалом

Пока вы не попросили иного, asynq retry делает до 25 попыток для каждой задачи: это умолчание зашито в постановку, и его же вы видите в TaskInfo в поле MaxRetry. Счётчик сделанных повторов живёт рядом — поле Retried растёт с каждой неудачей, а NextProcessAt показывает расчётное время следующей попытки. Изменить потолок можно опцией постановки: client.Enqueue(task, asynq.MaxRetry(5)) — и все три числа переедут в дашборд asynqmon, где retry-задачи сидят отдельной вкладкой. Сколько выбирать? Практика такая: уведомления и письма — три-пять попыток, потому что поздний успех там почти ничего не стоит; задачи вроде выгрузки в CRM или вебхука в партнёрскую систему — чаще с алертом на исчерпание, потому что потеря видна деньгами. Умолчание в 25 заточено под задачи, чей успех важен в любой день, — и оно же ловит тех, кто не думал о числе попыток вовсе. Между прочим, повторы задач go в asynq считаются на стороне воркера: постановка один раз записала потолок, дальше библиотека ведёт счёт сама, клиент в процесс не вмешивается. Ещё одна деталь дисциплины: потолок по умолчанию применяется ко всем постановкам без опции — поэтому в код-ревью полезно спрашивать не «сколько попыток здесь стоит», а «почему здесь умолчание годится». Задача с неявным потолком в двадцать пять выглядит безобидно ровно до первой недели живого сбоя внешнего сервиса.

Паузу между попытками считает DefaultRetryDelayFunc — формула, взятая у Sidekiq: n в четвёртой степени плюс пятнадцать секунд плюс случайная добавка rand(30) на (n+1), где n — сколько повторов задача уже сделала. Первый ретрай при n=0 назначается через 15–44 секунды: случайная добавка разводит волну одновременных сбоев, чтобы полсотни задач, упавших от одного упавшего сервиса, не вернулись в обработку одной волной. Дальше экспонента набирает силу быстро: пятая повторная попытка ждёт уже четыре с половиной — семь минут, одиннадцатая — почти три часа, а пауза перед двадцать пятой — почти четверо суток: 24 в четвёртой степени секунд — это три дня и двадцать часов. Номер попытки здесь и ниже означает число уже сделанных повторов: «перед двадцать пятой» значит при n=24, после двадцати четырёх неудач. Суммарно от первого сбоя до исчерпания всех 25 попыток проходит порядка двадцати суток — цифра, которая многих удивляет: экспонента честно говорит «если не сработало за час, будем пробовать редко». Сигнатура функции — func(n int, e error, t *Task) time.Duration: на вход номер попытки, ошибка и сама задача, на выходе пауза. Свою функцию можно поставить в Config.RetryDelayFunc — например, чтобы считать интервалы по типу ошибки, — но это отдельное ремесло, ему посвящён тринадцатый урок. Пока достаточно понимать арифметику умолчания: она объясняет, почему задача «висит» в retry то минуты, то сутки. И почему пауза — не таймер в памяти процесса: срок следующей попытки записан в Redis баллом, и пока воркеры живы, время текёт одинаково для всех реплик — двойных повторов из-за конкурирующих воркеров ждать не надо.

Повторяющаяся задача переходит в состояние retry и живёт в сортированном множестве Redis с баллом-временем следующей попытки — вы уже видели это устройство в пятом уроке про отложенные задачи: retry и scheduled внутри библиотеки близнецы, разница только в том, кто назначил время. Дальше всё то же самое: воркеры опрашивают расписание с интервалом в несколько секунд, созревшая задача переходит в pending и забирается свободным горутинам. Поскольку множество живёт в Redis, повторы переживают рестарты воркеров, клиентов и самого контейнера Redis — упавшая задача не зависит от жизни процесса. В asynqmon retry-задачи видны отдельной вкладкой с последней ошибкой и временем следующей попытки — шестнадцатый урок покажет, что там смотреть в первую очередь. Практический вывод для мониторинга: длина retry-вкладки — симптом внешних проблем. Десяток задач с одинаковым LastErr — упал внешний сервис, а не ваш код. И наоборот: разброс ошибок на одной вкладке — повод смотреть в собственный код. Для дашборда полезно помнить, что вкладки scheduled и retry читаются вместе: длина первой — ваши обещания, длина второй — чужие сбои, и смешивать их в одном алерте — верный способ перестать понимать, что происходит.

Когда счётчик догоняет потолок — Retried стал равен MaxRetry и попытка снова не удалась — asynq отправляет задачу в состояние archived. Архив — не кладбище, а досье: задача остаётся в Redis со всей историей, включая LastErr и LastFailedAt, и видна в asynqmon отдельной вкладкой. Разобрать её можно двумя руками: Inspector умеет запускать задачу заново и удалять — им занимается пятнадцатый урок; в дашборде те же действия есть кнопками. Важно не путать архив с удалением: данные на месте, исполнение прекратилось. Есть и второй путь в архив — ошибка SkipRetry, с которой хендлер говорит «не повторять вообще, неси сразу в архив»; это инструмент для ошибок, которые не исправятся повтором, и его разбор — в четырнадцатом уроке. Держите в голове симптом: растущая вкладка archived почти всегда означает, что где-то сломалось то, чинить должен человек, — очередь честно всё это время повторяла, а потом призналась. Ручной запуск из архива — не ритуал прощения, а инструмент: починили endpoint, запустили задачу заново, проверили результат — и удалили, не оставляя хвостов.

Повторы задач go не бесплатны, и считать цену стоит в двух валютах. Первая — слоты воркера: каждая повторная попытка занимает тот же пул Concurrency, что и свежие задачи, поэтому тысячный ретрай бессмысленного вебхука конкурирует с живыми письмами. Вторая — внешние системы: SMTP, платёжные шлюзы и партнёрские API сами устают от повторов, и волна ретраев после аварии способна положить их повторно. Есть в конфиге и редкий, но полезный винтик: функция IsFailure решает, считать ли возвращённую ошибку сбоем; если она вернёт false, счётчик повторов не вырастет и статистика очереди не испортится. Классический случай — ошибка валидации payload: задача без обязательного поля не исправится повтором, и засчитывать её сбоем значит портить метрики и жечь попытки впустую. Спорное мнение в тему: я не люблю ретраи с бесконечным потолком «на всякий случай» — бесконечный повтор означает, что где-то нет алерта. Потолок и ручной запуск из архива дают предсказуемую точку, где задача требует человека. О том, как считать интервалы по своей логике — например, длиннее для платёжных ошибок и короче для сетевых, — говорит тринадцатый урок; он заменяет формулу целиком через Config.RetryDelayFunc.