Разделы

Фоновые задачи и очереди

Фоновые задачи позволяют отдать работу платформе и сразу вернуться: поставьте вызов в очередь по HTTP, мгновенно получите jobId, а очередь выполнит функцию с ретраями, бэкоффом и dead-letter-очередью — без Redis, парка воркеров и самописного цикла опроса.

Задачи выполняют те же функции, что вы деплоите для HTTP-трафика, — с теми же секретами, слоями и наблюдаемостью. Отличается только триггер: durable-строка в очереди вместо живого запроса.

Жизненный цикл задачи

Каждая задача проходит небольшой и явный конечный автомат. Воркер забирает PENDING-задачи пачками, выполняет их в статусе RUNNING и записывает SUCCEEDED — либо планирует ретрай при сбое. Когда попытки исчерпаны, задача попадает в DEAD — dead-letter-состояние, где можно изучить ошибку и вручную вернуть задачу в очередь.

Конечный автомат фоновой задачи: PENDING в RUNNING, петля ретраев с бэкоффом обратно в PENDING, затем SUCCEEDED — или DEAD после исчерпания попыток со стрелкой ручного requeue
Статусы задач. Зависшую RUNNING-задачу возвращает в PENDING рипер по visibility-таймауту через 22,5 минуты.

Постановка в очередь и опрос

Постановка — один HTTP-вызов; ответ — 202 Accepted с идентификатором задачи. Дальше опрашивайте эндпоинт задачи (или подпишитесь на события запусков в консоли), чтобы получить результат:

curl
# Enqueue: returns immediately with a job id (the function runs in the background)
curl -X POST "https://api.inquir.org/functions/{functionId}/invoke-async" \
  -H "Authorization: Bearer $INQUIR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"event": {"orderId": "ord_123"}}'
# -> { "jobId": "…", "status": "PENDING" }

# Poll until the job reaches a terminal state
curl "https://api.inquir.org/jobs/{jobId}" \
  -H "Authorization: Bearer $INQUIR_API_KEY"
# -> { "status": "SUCCEEDED", "resultJson": … }  (or FAILED / DEAD with lastError)

Ретраи и бэкофф

Ретраи включаются на каждую постановку: передайте maxAttempts (до 100), и неудачные попытки вернутся в очередь с экспоненциальным бэкоффом — 1 с, 2 с, 4 с и далее, с потолком 5 минут и джиттером против эффекта толпы.

  • maxAttempts считает попытки целиком, а не только ретраи; по умолчанию — 1 (без ретраев).
  • Задача, зависшая в RUNNING дольше visibility-таймаута (22,5 мин), считается упавшей и возвращается в очередь — пишите обработчики так, чтобы повторная доставка была безопасной.
  • Поддерживается отложенный старт — до 7 дней; удобно для напоминаний и окон охлаждения.

Идемпотентность и контроль конкурентности

Две опции при постановке избавляют систему от дублей и лавин:

  • idempotencyKey — повторная постановка с тем же ключом вернёт исходную задачу вместо дубликата (в ответе будет флаг deduplicated).
  • concurrencyKey + concurrencyLimit — ограничьте, сколько задач с одним ключом выполняются одновременно (на клиента, на репозиторий — на что угодно).
  • priority — при глубокой очереди задачи с большим приоритетом забираются первыми.

Dead-letter-очередь

Когда падает последняя попытка, задача становится DEAD с финальной ошибкой, а в историю записывается терминальная FAILED-инвокация. Мёртвые задачи видны в консоли: устраните причину, нажмите requeue — и задача вернётся в PENDING со свежим запасом попыток.

Задачи, пайплайны или durable-оркестрация

Берите задачу, когда одна функция должна один раз отработать в фоне. Берите пайплайн, когда несколько функций образуют воркфлоу с ветвлением и fan-out. Берите durable-оркестрацию, когда поток должен спать на таймерах или ждать внешних событий часами и днями. Внизу у всех трёх — одна и та же очередь.