Когда лимиты таймаута serverless блокируют медленную работу
Каждая serverless-платформа ограничивает время выполнения функции. Эти лимиты разумны для HTTP-хендлеров, но болезненны для медленной фоновой работы. Выход — не увеличение таймаута, а разделение HTTP-приёма и асинхронного выполнения с цепочками шагов пайплайна, каждый из которых укладывается в свой бюджет.
Обновлено: 2026-06-28
Кратко
Суть ответа
Когда лимиты таймаута serverless блокируют медленную работу. Inquir разделяет HTTP-приём и асинхронное выполнение. HTTP-хендлер валидирует вход, ставит durable-задачу в очередь и сразу возвращает 202 — укладывается в любой таймаут платформы. Задача затем работает вне HTTP-окна со своим бюджетом таймаута (до 15 минут на шаг), а очередь повторяет упавшие шаги с backoff.
Когда подходит и когда нет
- Работа стабильно занимает больше HTTP-таймаута платформы
- Вы упираетесь в Vercel 60 с, Lambda 900 с или Workers 30 с CPU на фоновых задачах, попавших в HTTP-хендлеры
На что обратить внимание
- Увеличение таймаута — временная мера, а не архитектурное решение. Работа всё равно выполняется в одном контексте с одним failure domain: сбой на 14-й минуте 15-минутной Lambda перезапускает все 15 минут.
- Рекурсивные вызовы (вызов самого себя для «продолжения» работы) теряют контекст между вызовами, рискуют двойной записью при сбое и невидимы для инструментов наблюдаемости, которые ждут один execution trace на задачу.
Ситуация: нагрузка и где обычно ломается
Реальные лимиты таймаута на популярных serverless-платформах
- Vercel Serverless Functions: 60 с (Pro), 300 с (Enterprise)
- AWS Lambda: максимум 900 с (15 мин)
- Cloudflare Workers: 30 с CPU-времени (Bundled plan)
- Supabase Edge Functions: 60 с
Эти лимиты существуют не просто так — serverless-функции созданы для быстрых stateless HTTP-хендлеров. Проблема возникает, когда команды пытаются запускать фоновую работу через тот же путь выполнения функции: обработка CSV, массовая синхронизация, многошаговые ML-пайплайны или ночная архивация данных.
Компромиссы
Почему обходные пути разваливаются
Увеличение таймаута — временная мера, а не архитектурное решение. Работа всё равно выполняется в одном контексте с одним failure domain: сбой на 14-й минуте 15-минутной Lambda перезапускает все 15 минут.
Рекурсивные вызовы (вызов самого себя для «продолжения» работы) теряют контекст между вызовами, рискуют двойной записью при сбое и невидимы для инструментов наблюдаемости, которые ждут один execution trace на задачу.
Как Inquir помогает в этом сценарии
Цепочки пайплайнов как выход из лимитов таймаута платформы
Inquir разделяет HTTP-приём и асинхронное выполнение. HTTP-хендлер валидирует вход, ставит durable-задачу в очередь и сразу возвращает 202 — укладывается в любой таймаут платформы. Задача затем работает вне HTTP-окна со своим бюджетом таймаута (до 15 минут на шаг), а очередь повторяет упавшие шаги с backoff.
Для работы дольше 15 минут на шаг декомпозируйте на несколько шагов — каждый укладывается в бюджет, пайплайн их последовательно соединяет. Смотрите страницу архитектуры многошаговых пайплайнов для fan-out, merge и ретраев на шаг.
Сравнение
Serverless platform timeout comparison
HTTP function limits for common platforms, and how Inquir pipeline steps compare.
| Platform | HTTP function limit | Background / async path |
|---|---|---|
| Vercel | 60s (Pro) / 300s (Enterprise) | No built-in background execution |
| AWS Lambda | 900s (15 min) max | Async invoke still caps at 900s |
| Cloudflare Workers | 30s CPU time (Bundled) | 60s with paid Unbound plan |
| Supabase Edge Functions | 60s | No built-in pipeline execution |
| Inquir (HTTP handler) | 5s default / 900s max | — |
| Inquir (pipeline step) | — | Up to 15 min per step; chain steps for longer work |
Что вы получаете на платформе
Что даёт выполнение через пайплайн
Работа, переживающая лимиты HTTP-таймаута
HTTP-хендлер возвращает 202 за миллисекунды. Шаг пайплайна выполняет медленную работу с собственным таймаутом — без общего контекста с HTTP-путём.
Изоляция сбоев на шаг
Сбой в шаге 3 из 5 не перезапускает шаги 1 и 2. Повторяется только упавший шаг — с собственным числом ретраев и backoff.
Опрос статуса и колбэки
Верните jobId в ответе 202. Клиент опрашивает эндпоинт статуса или получает вебхук-колбэк по завершении пайплайна.
Многошаговая композиция для очень долгой работы
Цепляйте шаги для превышения лимита одного шага: каждый до 15 минут. Четырёхшаговый пайплайн покрывает час работы с чекпоинтами между шагами.
Что сделать дальше, по шагам
Паттерн: HTTP принимает, пайплайн выполняет
HTTP-хендлер валидирует и триггерит
Разберите вход, валидируйте, поставьте durable-задачу в очередь, верните 202 с jobId. Завершается значительно быстрее любого HTTP-таймаута платформы.
Шаг пайплайна делает медленную работу
Шаг работает вне HTTP-окна с собственным бюджетом таймаута (до 15 мин). Цепляйте шаги для работы, превышающей бюджет одного шага.
Клиент опрашивает или получает колбэк
Используйте jobId для опроса эндпоинта статуса — либо финальный шаг пайплайна отправит клиенту вебхук-колбэк по завершении.
Пример кода
HTTP → handoff в пайплайн: выход за лимит таймаута
HTTP-хендлер возвращает 202 немедленно — никогда не приближается к таймауту платформы. Шаг пайплайна выполняет медленную работу вне HTTP-окна.
export async function handler(event) { const { fileUrl } = JSON.parse(event.body || '{}'); if (!fileUrl) return { statusCode: 400, body: JSON.stringify({ error: 'fileUrl required' }) }; // Returns in <100ms — well inside Vercel 60s, Lambda 900s, or any other platform limit const { jobId } = await global.jobs.enqueue('import-csv', { fileUrl }); return { statusCode: 202, body: JSON.stringify({ jobId, status: 'started' }) }; }
export async function handler(event) { // Runs outside HTTP window; this step has up to 15 min timeout const { fileUrl } = event.payload ?? {}; const rows = await downloadAndParseCSV(fileUrl); // may take several minutes for large files for (const batch of chunk(rows, 500)) { await db.upsertBatch(batch); // idempotent by row ID } return { imported: rows.length, fileUrl }; }
Когда подходит и когда нет
Когда применим паттерн HTTP→пайплайн
Когда это уместно
- Работа стабильно занимает больше HTTP-таймаута платформы
- Вы упираетесь в Vercel 60 с, Lambda 900 с или Workers 30 с CPU на фоновых задачах, попавших в HTTP-хендлеры
Когда лучше выбрать другое
- Работа завершается менее чем за 10 секунд — оставьте синхронной в HTTP-хендлере для простоты отладки
Вопросы и ответы
Вопросы и ответы
Шаг пайплайна правда без ограничений по времени?
Нет. У каждого шага настраиваемый таймаут — до 15 минут (900 000 мс). Это значительно больше любого HTTP-таймаута функции, но не бесконечно. Для работы дольше 15 минут цепляйте несколько шагов — смотрите страницу долгих serverless-задач.
Чем отличается от увеличения Lambda-таймаута до 900 с?
Lambda ограничивает всё выполнение 900 с в одном контексте. Inquir цепляет шаги, каждый с собственным 15-минутным бюджетом и независимыми ретраями. Сбой на 14-й минуте одного шага не перезапускает уже завершённый предыдущий шаг.
Что если клиенту нужен синхронный результат?
Клиент должен опрашивать эндпоинт статуса по jobId или получить вебхук-колбэк от финального шага пайплайна. По-настоящему синхронная длительная работа принципиально несовместима с HTTP-таймаутами serverless на любой платформе.