inngest-durable-functions

Навык Inngest посвящён TypeScript-функциям, которые должны переживать падение процесса, автоматически повторять неудачные операции, запускаться по расписанию, реагировать на события и продолжать работу после инфраструктурных сбоев. Базовая модель — durable execution: каждый side effect и недетерминированная операция помещается в step, завершённые steps сохраняются и memoized, а состояние позволяет продолжить функцию с нужного места. Это подходит для webhook handlers, которые могут потерять событие, flaky cron jobs, фоновых задач, остановившихся посередине, и workflow, которым нужно возобновление, а не повторение всей функции с нуля. Ключевая граница проходит вокруг step.run. Внутрь step следует помещать API-запросы, чтение и запись базы данных, файловый ввод-вывод и любую недетерминированную работу, которую нужно отдельно retry-ить. Чистые вычисления, простую валидацию и детерминированные преобразования не требуется превращать в steps; logging также остаётся снаружи. Источник отдельно показывает опасность Date.now() вне step: после повторного выполнения timestamp может быть рассчитан заново. Если timestamp или другой внешний результат нужен как часть результата, его следует получить внутри одного именованного шага, чтобы memoization удерживала уже завершённое действие. Ограничения функции нужно учитывать заранее. Один запуск может содержать не более 1 000 steps, один step может вернуть не более 4 MB, а общее состояние function run, включая event data, step output и function output, ограничено 32 MB. Каждый step является отдельным HTTP request и добавляет примерно 50–100 ms overhead. При приближении к лимитам источник предлагает разбивать большую функцию на несколько функций, соединённых через step.invoke() или step.sendEvent(). Поэтому durable execution не является разрешением дробить каждый мелкий оператор: избыточное количество steps увеличивает сетевую стоимость и усложняет наблюдение за workflow. Создание функции начинается с уникального и неизменяемого id, массива triggers и async handler с event и step. Поддерживаются event triggers с условными фильтрами, cron triggers с timezone, несколько triggers в одной функции и вызов другой функции как step через step.invoke. В источнике приведён предел до десяти triggers и показано, как совместить ручное событие с расписанием. Для бизнес-операций retries и concurrency задаются в конфигурации функции, но конкретные значения должны следовать идемпотентности операции, внешним rate limits и допустимому времени ожидания, а не копироваться вслепую из примера. Идемпотентность рассматривается на двух уровнях. На стороне producer можно задать event id для дедупликации отправки на 24 часа. На стороне consumer функция получает idempotency key, например cartId или составной ключ пользователя и организации, чтобы повторный запуск не выполнил одну бизнес-операцию дважды. Для side effects этого недостаточно без проверки самого обработчика: ключ должен действительно соответствовать бизнес-идентичности, а запись или внешняя операция должны выдерживать повтор. Важны также cancellation patterns: функция может ждать step.sleepUntil, а cancelOn сопоставляет новое событие с исходным через выражения event и async. Наблюдаемость и обработка ошибок являются частью workflow, а не финальной косметикой. Шаги получают независимые retries, поэтому ошибку нужно локализовать так, чтобы повтор не создавал дубликаты и не скрывал исходную причину. Состояние, output и размер событий следует держать компактными, а logging не смешивать с side effect, который должен быть memoized. Навык даёт структуру для устойчивых event-driven и scheduled jobs, но не выбирает за команду схему данных, политику повторов, мониторинг, секреты, очереди или правила ручного вмешательства после исчерпания retries. Карточка применима к TypeScript и описывает модель Inngest, её triggers, steps, memoization, retries, idempotency, cancellation и лимиты. Для Python или Go сам источник направляет к документации Inngest, поэтому это описание нельзя выдавать как отдельный language-specific workflow для других стеков. После проектирования нужно проверить размер event и step outputs, число steps, поведение при повторе, cancellation, concurrency и реальные внешние side effects. Это подтверждает пригодность конкретной функции, но не является гарантией доставки, бизнес-корректности или автоматическим аудитом кода.