Comments 4
Про «resume from where it stopped» согласен: без своего состояния снаружи на такой перезапуск лучше не закладываться.
Согласен и добавлю оговорку в ту же сторону: состояние снаружи отвечает на вопрос «где остановились», но не на вопрос «безопасно ли пройти этот шаг второй раз». Поэтому в списке из статьи перезапуск и идемпотентность — разные пункты. Перезапуск говорит, откуда продолжать. Идемпотентность нужна там, где узел исполняется повторно: при том же перезапуске и при повторной доставке события. Упавший шаг мог успеть сделать половину работы, а событие могло прийти дважды — про это состояние снаружи не знает ничего.
Про штатную настройку. У Save execution progress документация следующей же фразой оговаривается сама: «This may increase latency». Насколько — не пишет. Вместе с объяснением участника форума («…n8n will write and load the execution progress to/from the database after each step», запись от 9 декабря 2021 года) я читаю это как плату за саму запись прогресса, но цифру каждому придётся мерить у себя. Там же в ветке видно и границу настройки: она страхует от перезапуска процесса, а не от того, что один узел упал, пока инстанс жив.
https://docs.n8n.io/build/manage-workflows/configure-workflow-settings.md
https://community.n8n.io/t/save-execution-progress-resume-explaination/9782
Плотный разбор) тезис про отсутствие state и нативной идемпотентности в n8n полностью подтверждается практикой. При self-hosted развертывании под реальный продукт, платформу приходится использовать строго как оркестратор графа.Всю логику дедупликации, асинхронный буфер и защиту от Race Condition (особенно при параллельной доставке вебхуков мессенджеров) предсказуемо приходится выносить наружу - в тот же Redis 7. Одиночные MVP-ключи при росте конкурентных запросов быстро приводят к коллизиям, поэтому в боевых условиях состояние и изоляция контекста закрываются через полноценную Redis Queue. Вопрос: если n8n в итоге рассматривался только как промежуточный этап, к какому архитектурному стеку для реализации этих 6 пунктов надежности пришли в итоге?
Сразу поправлю сам себя: я утверждал не отсутствие механизмов, а отсутствие их описания. Поиск по полному индексу страниц (docs.n8n.io/sitemap.md) на 27 августа даёт по строке «idempot» ноль совпадений, а Save execution progress участник форума объясняет через крах инстанса. Что там внутри на самом деле, из этого не следует. Ваш опыт эксплуатации self-hosted-инстанса под нагрузкой я не оспариваю: эксплуатация под нагрузкой и чтение страниц — разные весовые категории.
По вопросу отвечу настолько, насколько считаю возможным. Стек назвать могу: бэкенд — Python 3.12 и FastAPI, SQLAlchemy в асинхронном режиме, Alembic, httpx, aiosmtplib; состояние — в PostgreSQL 17; очереди фоновых задач и расписания — Redis, arq, croniter; интеграции — OAuth 2.0 с Яндекс 360, SMTP и CalDAV; фронтенд — React 18 и TypeScript.
А то, о чём вы спрашиваете дальше, — дедупликация, ключи, изоляция контекста, — это внутренняя механика, наружу мы её не отдаём. В статье есть раздел «Слабое место этого текста», он написан ровно про такой вопрос: по моему же чек-листу моя сторона остаётся для вас обещанием. Честнее повторить это здесь, чем отделаться общими словами.
Про промежуточный этап: в плане он был — n8n под капотом, со слоем абстракции сверху. В работу этот этап так и не пошёл, ядро стали делать сразу.
Строка «resumes from where it stopped» увела меня в ветку форума 2021 года и в пять вопросов к движку автоматизации