Зелёный статус в n8n ничего не доказывает

На форуме n8n за одну неделю всплыли два разбора одного и того же явления с разных сторон.

Один инженер описал запуски, которые зависают в очереди, пока воркер простаивает.

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

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

Для компании, которая завязала CRM, рассылки и платежи на автоматизацию, разница между этими двумя фактами стоит денег.

Красный run вызывает алерт и человека, который идёт разбираться.

Повторный запуск неидемпотентного POST - запись в CRM, списание по платежу - не вызывает ничего.

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

Ровно с этой болью столкнулась команда, описавшая свой кейс на self-hosted n8n с Redis-очередью и MCP Server Trigger, дёргающим внешний HTTP-инструмент: дубли записей в CRM от одной формы заставили их городить временный idempotency-guard поверх штатной очереди.

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

Идемпотентность здесь - отдельный слой логики, спроектированный под конкретный бизнес-процесс.

Галочка в настройках очереди её не даёт.

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

Надёжный воркфлоу, которому можно доверить платёж или рассылку клиентам, простым не бывает - за ним стоит идемпотентный ключ на каждую небезопасную операцию, реконсилер, который спрашивает у провайдера, действительно ли случилось то, что заявлено, и таймауты локов, посчитанные под реальную длительность задачи, а не взятые по умолчанию.

Именно это отличает конвейер автоматизации, который держит нагрузку и деньги компании, от макроса, который однажды подведёт молча.

Когда KT.Team ставит n8n или MCP-интеграции поверх очередей вроде Kafka, эта прослойка - сверка исхода с провайдером, идемпотентность на уровне бизнес-ключа, а не запроса - идёт в проект с самого начала, а не добавляется после первого инцидента с задвоенным списанием.