Своя политика ретраев

Сигнатура — type RetryDelayFunc func(n int, e error, t *asynq.Task) time.Duration: на вход номер попытки, ошибка хендлера и сама задача, на выход — пауза перед следующей попыткой. Ставится в asynq.Config сервера и заменяет дефолт для всех задач этого воркера. Номер n — сколько повторов задача уже сделала: при первой неудаче он равен нулю, при второй — единице; это тот же счётчик, что видно в info.Retried и GetRetryCount. Функция вызывается только тогда, когда ретрай действительно состоится: после исчерпания MaxRetry или при SkipRetry задача уходит в архив, и до вашей формулы дело не доходит. Возвращённое значение — честная пауза: вернёте пять минут, задача ляжет в retry-множество Redis с баллом через пять минут; вернёте ноль — следующая попытка встанет в очередь сразу же, без паузы. Внутри функции доступен весь контекст неудачи: текст ошибки, её тип через errors.As, тип задачи через t.Type() и даже payload через t.Payload(). Это и есть источник гибкости: политика может знать про Retry-After провайдера, про окно обслуживания и про то, какая из ваших задач вообще терпит повтор.

Свои повторы go становятся полезными, когда функция читает ошибку. Идиома — свой тип ошибки, который несёт подсказку о повторе: type RateLimitedError struct{ RetryAfter time.Duration } у обёртки HTTP-вызова или у адаптера провайдера. В RetryDelayFunc ошибку достают через errors.As: если это RateLimitedError — вернуть её RetryAfter, и попытка уйдёт ровно тогда, когда разрешил провайдер; если сетевая — короткая пауза с нарастанием; если ошибка валидации — здесь же решение SkipRetry принимает хендлер, а не функция паузы, об этом говорит четырнадцатый урок. Разделение труда получается честное: хендлер решает, повторять ли вообще, функция паузы — когда повторять. Тот же приём работает и в обратную сторону: сервисный слой может возвращать обычные ошибки, а адаптер-обёртка в хендлере оборачивать их в типы с подсказками — тогда знание про Retry-After не расползается по коду. Важно лишь не переборщить: каждый новый тип ошибки — контракт между хендлером и политикой, который придётся держать в голове и в тестах. Две-три категории с ясными именами стоят десяти нюансов.

Второй аргумент ветвления — сама задача. Один воркер обслуживает десятки типов задач, а политика нужна разная: письма прощают минуты, платежи требуют секунд, генерация отчётов — часов. Switch по t.Type() возвращает каждой категории свою формулу — и весь зоопарк живёт в одном месте, а не в настройках десятка серверов. Типы сравнивайте через именованные константы из общего пакета, а не строковые литералы: префиксный switch устареет молча, если кто-то переименует тип и не найдёт все вхождения руками. Если политики у типов радикально разные, прямым путём остаётся разделение по очередям: отдельный asynq.Server со своим Config для платежей и для почты — об этом говорит двадцатый урок про масштабирование. Payload в функции паузы читается осторожно: t.Payload() возвращает сырые байты, и разбор JSON на каждую неудачу — работа, которой там не место. Если политике действительно нужен payload — например, приоритет тенанта из тела задачи — распарсите лёгкое поле или положите нужное в заголовок задачи при постановке. Правило экономности простое: функция паузы вызывается на каждой неудаче в горячем пути воркера, и работа в десять микросекунд здесь умножается на все сбои вашей системы.

Отступление от экспоненты — не всегда благо, и полезно знать, что дефолт делает хорошо. Экспонента с джиттером универсальна: она не знает ничего и потому не врёт; она растёт быстро и спасает от долбёжки при затяжном сбое. Честные поводы для отступления три. Первый — внешний мир говорит сам: Retry-After, окна обслуживания, квоты; здесь экспонента слепа по определению, и её место занимает подсказка провайдера. Второй — бизнес-ритм: повтор платежа через сутки после сбоя бесполезен, клиент ушёл; платежам нужна плотная серия коротких попыток, а не сутки ожидания. Третий — потолок: дефолтная формула на больших n уходит в дни, и для задач, которые должны решиться в час, это архив, а не ретрай. Напомним числа из шестого урока без пересказа: первая неудача ждёт пятнадцать-сорок пять секунд, пятая — уже от четырёх с половиной до семи минут, а к двадцать пятой попытке пауза подбирается к четырём суткам; для задачи с часом жизни это не политика, а наказание. Потолок, впрочем, делается без отказа от экспоненты: вызовите DefaultRetryDelayFunc внутри своей функции и ограничьте результат сверху — минимум из формулы и вашего лимита. Так вы сохраните и случайность, и быстрый рост на старте, и контроль над хвостом. Полный отказ от дефолта оправдан, когда у вас есть собственные данные о том, когда повтор имеет смысл, — иначе вы просто напишете экспоненту хуже, чем её написали авторы библиотеки.

Политика — чистая функция от трёх аргументов, и тестировать её одно удовольствие: собрать ошибку, собрать задачу, сравнить duration. Покройте минимум четыре случая: первая неудача с n=0, десятая с n=9, ваша кастомная ошибка с подсказкой и незнакомая ошибка, уходящая в дефолт. Удобный каркас — табличный тест со срезом структур: имя случая, номер попытки, заготовка ошибки, ожидаемая длительность; новый класс ошибок добавляется строкой, а не новым тестом. Конструировать задачу в тесте можно через asynq.NewTask с пустым payload: политике важен только тип, который вы вернёте через t.Type(). Ещё один полезный случай — крайний: политика при n, равном MaxRetry минус один, должна вернуть разумную паузу, ведь это последний шанс задачи. Отдельный тест стоит написать на джиттер: прогоните формулу сто раз и проверьте, что результаты не одинаковые — иначе однажды джиттер потеряется при рефакторинге, и вы узнаете об этом по графику Redis. Из граблей самые частые: забыть, что n начинается с нуля, и получить первую паузу вдвое длиннее задуманной; тяжелоразбираемый payload в горячем пути; логирование на каждую неудачу, раздувающее логи при массовых сбоях. Смотреть на политику в бою удобнее всего через retry-список: поле NextProcessAt у задач показывает, когда именно ваша формула назначила следующую попытку — пауза видна как расстояние между LastFailedAt и NextProcessAt. Наконец, помните про границу ответственности: политика управляет только паузой, а судьбой задачи — повторять ли вообще — распоряжаются MaxRetry на постановке и SkipRetry в хендлере; попытка управлять повтором из функции паузы невозможна по построению.