hiapi /v1/tasks: задачи зависают или истекают по таймауту — руководство по диагностике и повторным попыткам

Почему асинхронные задачи зависают и истекают по таймауту

Асинхронная задача в /v1/tasks — это контракт между тремя сторонами: вашим клиентом, платформой HiAPI и вычислительным ресурсом, который фактически выполняет работу. Зависание почти всегда означает, что один из уровней ждёт другой, и первое, что нужно сделать при отладке, — понять, какой именно уровень, потому что методы исправления для каждого уровня разные, а слепые повторные попытки только ухудшают ситуацию.

Вот жизненный цикл, который вы должны держать в голове:

Жизненный цикл, по этапам

1. Отправка (Submit) — ваш клиент отправляет запрос, платформа принимает его и возвращает идентификатор задачи.
2. Постановка в очередь (Enqueue) — задача планируется к выполнению. Именно на этом этапе при высокой нагрузке чаще всего возникает задержка, и он хуже всего виден вам.
3. Выполнение (Run) — вычислительный ресурс обрабатывает задачу. Время здесь полностью зависит от рабочей нагрузки и не связано с вашим HTTP-клиентом.
4. Завершение (Complete) — фиксируется конечное состояние, и результат можно получить по тому же идентификатору задачи.

«Зависание» редко бывает единичным событием; обычно это один из следующих случаев:

• Задача действительно всё ещё выполняется. Длинный ввод, большой вывод или загруженная очередь удлиняют этап 3. Ничего не сломано — вы просто слишком торопитесь.
• Задача поставлена в очередь, но ещё не начала выполняться. Этап 2 может тянуться долго, и с вашей стороны это выглядит точно так же, как зависание.
• Ваш клиент сдался слишком рано. Вы установили HTTP-таймаут на запрос состояния, а не на задачу, поэтому платформа работает нормально, а ваш процесс прерывается.
• Задача достигла конечного состояния, но вы этого не обнаружили. Ваш цикл опроса остановился, упал или завершился до получения ответа.
• Настоящий сбой на стороне платформы. Встречается реже, но бывает, и это единственный случай, когда стоит думать о повторной попытке на уровне платформы.

Ключевое заблуждение

Самая распространённая причина таймаутов, созданных своими руками, — смешение двух часов. Ваш HTTP-запрос для проверки состояния должен быть коротким — это всего лишь чтение. У задачи же есть собственный, гораздо более длительный срок выполнения. Если вы используете одно и то же значение таймаута для обоих, вы отменяете здоровые задачи, а затем повторяете их, дублируя работу, которая почти завершилась.

Прежде чем что-либо менять, определите, в каком из пяти описанных случаев вы на самом деле находитесь. Всё остальное в этом руководстве зависит от этого ответа.

Шаг первый: соберите доказательства по задаче

Сдержите порыв менять код или запускать повторную попытку в первую же минуту. Зависание — это состояние, которое можно отлаживать только после того, как вы записали достаточно информации. Зафиксируйте следующее до вмешательства.

Что фиксировать по каждой задаче

• Идентификатор задачи, возвращённый при отправке. Это ключ ко всему; без него вы можете только гадать.
• Строку состояния, которую вы наблюдали последней, дословно, без пересказа.
• Метки времени: когда вы отправили задачу, когда был отправлен каждый запрос состояния, когда вернулся каждый запрос.
• Количество выполненных запросов состояния и их интервалы.
• Форму полезной нагрузки запроса — не обязательно полное содержимое, но достаточную для воспроизведения: размер входных данных, параметры и всё, что влияет на время выполнения.
• Клиентский срок выполнения, который вы установили (если он есть), и сработал ли он.

Вручную проверьте тот же идентификатор ещё раз

Прежде чем делать выводы, выполните новый запрос состояния для того же идентификатора задачи. Возможны два исхода:

• Состояние продвинулось. Задача жива; вы столкнулись с ошибкой опроса или таймаута, а не с ошибкой задачи. Переходите к разделу об опросе.
• Состояние не изменилось, а задача уже старая. Теперь у вас есть настоящая подозрительная задача, которая, возможно, застряла. Запишите, как долго она находится в этом состоянии, и сравните с вашими ожиданиями.

Записывайте это

Для каждой попытки сохраняйте короткую строку журнала: идентификатор, состояние, прошедшее время, принятое решение. Повторяющиеся зависания почти всегда диагностируются по истории, а не по текущему событию. Если вы не можете восстановить, что делала задача час назад, вы будете снова и снова отлаживать один и тот же сбой.

Ещё одно доказательство, о котором легко забыть: время суток и тип рабочей нагрузки. Если зависания сосредоточены на определённом типе входных данных, вы обнаружили закономерность, которую стоит сообщить, а не случайный сбой, который стоит повторять.

Правильно интерпретируйте состояние задачи

Состояние — это фактическая основа каждого решения о повторной попытке. Рассматривайте его как небольшой конечный автомат, где каждому состоянию соответствует ровно одно действие, чтобы вы никогда не повторяли задачу, которая всё ещё выполняется.

Состояния, которые вы увидите, и их значения

• Queued / pending (в очереди / ожидает) — принята, но не начата. Долгое пребывание здесь означает нагрузку на планировщик. Не повторяйте попытку; задача уже существует.
• Running / processing (выполняется / обрабатывается) — вычислительный ресурс работает. Всё в порядке. Ожидание — правильное действие.
• Succeeded / completed (успешно / завершена) — конечное состояние. Прочитайте результат и закончите.
• Failed / error (неудачно / ошибка) — конечное состояние, и его полезная нагрузка с ошибкой — ваш лучший материал для отладки. Прочитайте её перед любым решением.
• Cancelled / expired (отменена / истекла) — конечное состояние, вызванное политикой или вашими собственными действиями. Повторять ли попытку — это совершенно новое решение.
• Unknown или отсутствует — идентификатор не распознан. Это не состояние отказа, а состояние доказательства. Перечитайте идентификатор и убедитесь, что смотрите на правильный.

Два вопроса к любому состоянию

1. Это конечное состояние? Если нет, единственное правильное действие — ждать в пределах вашего бюджета.
2. Если это конечное состояние, можно ли его повторить? Успех повторять нельзя. Неудачу, возможно, можно, а возможно, и нет — сначала прочитайте ошибку. Неизвестный идентификатор требует расследования, а не повторной попытки.

Не выводите состояние из прошедшего времени

«Она выполняется уже десять минут, значит, точно зависла» — это догадка, а не диагностика. Прошедшее время говорит вам только о том, когда запрашивать состояние, и никогда — каково оно. Задача может долго пробыть в очереди, а затем успешно завершиться. Пусть вывод делает строка состояния; ваши часы определяют лишь, как часто вы спрашиваете.

Разработайте разумный ритм опроса

Большинство «зависаний» — это замаскированные ошибки опроса. Есть две основные модели отказа: опрос слишком агрессивен и подрывает собственную надёжность; опрос слишком наивен и никогда не замечает конечного состояния. Ограниченный ритм решает обе проблемы.

Начинайте медленно, увеличивайте интервал умеренно

Не опрашивайте в плотном цикле. Начните с короткого интервала, чтобы быстрые задачи быстро получали результат, затем увеличивайте интервал по мере старения задачи:

import time

def poll(job_id, check_status, deadline_s=600):
    start = time.monotonic()
    interval = 1.0
    while True:
        status = check_status(job_id)
        if status in ("succeeded", "failed", "cancelled", "expired"):
            return status
        if time.monotonic() - start > deadline_s:
            return "client_deadline_exceeded"
        time.sleep(interval)
        interval = min(interval * 1.5, 30.0)  # 设上限

Ключевые свойства: начальный интервал достаточно короток, чтобы ловить быстрые задачи; коэффициент роста делает длинные задачи недорогими; и есть верхняя граница, благодаря которой вы никогда не проспите час и не пропустите результат.

Всегда устанавливайте клиентский срок выполнения

Никогда не предполагайте, что платформа сама подаст сигнал о завершении. Установите собственный срок выполнения — максимальное время, которое вы готовы ждать — и рассматривайте его превышение как отдельный результат, а не как отказ. Это различие важно: результат client_deadline_exceeded означает «я больше не смотрю», а не «задача мертва». Записывайте именно так.

Два практических правила

• Ограничьте общее количество запросов. Цикл без максимального числа итераций — это грядущее зависание. Рассчитайте его исходя из вашего срока выполнения и верхней границы интервала.
• Разделяйте таймаут чтения и срок выполнения задачи. HTTP-вызов для получения состояния должен иметь собственный короткий таймаут. Если чтение состояния истекло по таймауту, повторите это чтение — ни в коем случае не повторяйте задачу.

Уважайте конечную точку

Опрос дёшев, но не бесплатен. Если вы проверяете сотни задач, распределите их во времени и повторно используйте один клиент. Если сомневаетесь, более медленный темп почти всегда безопаснее: задача, которую стоит ждать шесть минут, стоит того, чтобы подождать шесть минут и тридцать секунд.

Решение между повторной попыткой и повторной отправкой

Это решение, где корректность сталкивается со стоимостью. Повторить ту же задачу и отправить новую задачу — не взаимозаменяемые действия; неправильный выбор либо дублирует работу, либо оставляет здоровую задачу без внимания.

Правило принятия решения

Проходите по пунктам по порядку:

1. Задача в конечном состоянии? Если нет, не повторяйте и не отправляйте заново. Ждите. Повторная попытка для всё ещё выполняющейся задачи дублирует работу.
2. Если конечное состояние, что оно говорит? Успех означает, что вы закончили. Неудача содержит полезную нагрузку с ошибкой — сначала прочитайте её.
3. Может ли эта неудача быть временной? Таймауты при высокой нагрузке, кратковременная недоступность, ограничение скорости — всё это кандидаты на повторную попытку.
4. Может ли эта неудача быть постоянной? Некорректный ввод, неподдерживаемые параметры, неправильно сформированная полезная нагрузка — они будут падать одинаково сколько бы раз вы ни пытались. Исправьте запрос.

Повторяйте ту же задачу, если…

Задача существует, и она перешла в конечное состояние неудачи по причине, которая может не повториться, и семантика платформы для этой задачи допускает ещё одну попытку. Вы повторно используете идентификатор, сохраняете историю и избегаете создания второй задачи, делающей то же самое.

Отправляйте заново как новую задачу, если…

• Идентификатор неизвестен или его больше невозможно получить — повторять нечего.
• Исходная задача явно истекла по политике, и повторной попытке не к чему прикрепиться.
• Вам нужно изменить входные данные. Повторная попытка — это тот же запрос; исправление — это новый запрос. Никогда не позволяйте повторной попытке означать не то же, что исходный запрос.

Асимметрия стоимости

Повторная попытка для всё ещё выполняющейся задачи удваивает объём работы для одного результата. Повторная отправка — это явно новая задача: новый идентификатор, новый жизненный цикл и новые затраты. Оба инструмента законны; оба следует применять обдуманно. Эмпирическое правило: повторяйте попытку при неопределённости инфраструктуры, отправляйте заново при определённости входных данных.

Сделайте повторные попытки безопасными

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

Думайте в терминах идемпотентности

Для каждого типа задач, которые вы запускаете, спросите: если она выполнится дважды, результат останется правильным? Если ответ отрицательный — например, задача добавляет запись или вызывает побочный эффект в нижележащей системе — тогда ваша логика повторных попыток должна управляться состоянием, а не таймером. Повторяйте только конечные неудачи и только после того, как новый запрос состояния подтвердил это состояние.

Ограничивайте количество попыток

Каждому циклу повторных попыток нужны максимальное количество попыток и максимальное общее время, причём оба должны проверяться явно. Неограниченный цикл повторных попыток — это просто более медленное и более дорогое зависание. Когда бюджет исчерпан, выведите ошибку наружу — не глотайте её молча.

Добавляйте задержку между попытками

Сами повторные попытки также должны быть разнесены во времени и увеличивать интервал с каждой неудачей. Немедленный повтор для уже отказавшей зависимости обычно снова падает и добавляет нагрузку уже перегруженной системе.

Записывайте попытки, а не только ошибки

Фиксируйте каждую попытку: идентификатор задачи, состояние на момент решения, номер попытки, использованный интервал и результат. Это разница между «иногда зависает» и «зависает по вторникам после обеда при больших входных данных». Второе можно исправить, первое — нет.

Никогда не скрывайте настоящие отказы

Если задача упала трижды, а ваш слой-обёртка возвращает только общую ошибку, вы отбросили те полезные нагрузки с ошибками, которые объясняют причину. Сохраняйте последнее состояние и сведения об ошибке вплоть до вызывающей стороны. Повторная попытка — механизм восстановления, а не сокрытия: она должна уменьшать вероятность того, что основная проблема останется незамеченной, а не наоборот.

Контрольный список для разбора повторяющихся зависаний

Зависание случилось один раз — исправьте ту конкретную задачу и двигайтесь дальше. Случилось дважды — пройдите этот список, иначе вы просто будете вечно платить за повторные попытки.

Контрольный список

• Классифицируйте инцидент. Это задача, которая всё ещё выполнялась, а вы перестали наблюдать; действительно застрявшая задача; клиентский таймаут; или состояние, которое вы не смогли прочитать? Если вы можете это сформулировать, вы уже решили половину проблемы.
• Проверьте расчёт опроса. Действительно ли работают верхняя граница интервала, срок выполнения и лимит попыток? Нет ли где-нибудь неограниченного цикла?
• Убедитесь, что таймауты разделены. Не смешивался ли когда-либо таймаут чтения состояния со сроком выполнения задачи?
• Пересмотрите решения о повторных попытках. Была ли какая-либо попытка сделана для задачи в неконечном состоянии? Была ли какая-либо повторная отправка дублированием всё ещё выполняющейся задачи?
• Проверьте полезные нагрузки с ошибками. Сохранены ли ошибки или их проглотила обёртка?
• Ищите закономерности во входных данных. Сгруппированы ли отказы по размеру полезной нагрузки, параметрам или типу рабочей нагрузки?
• Пересмотрите ожидания. Может быть, задача превысила ваш срок выполнения потому, что работа действительно такая большая? Тогда ошибка в сроке выполнения.

Превратите выводы в настройки по умолчанию

Каждый из пунктов выше должен стать практикой по умолчанию в вашем клиенте: ограниченный опросчик, отдельный результат срока выполнения, политика повторных попыток на основе состояния и структурированные журналы с ключом по идентификатору задачи. Сделав это, вы превратите следующее зависание в строку журнала, а не в потерянный день.

Асинхронная задача — это контракт, и он действует, пока вы уважаете её состояние. Отличайте всё ещё выполняется от никогда не завершится, ждите в ограниченном ритме, повторяйте только то, что можно безопасно повторить — и зависание останется мелкой неприятностью, а не аварией.