-
### Вход без проверки Участник форума разбирает простой случай.
-
Ручной триггер передаёт в HTTP Request ноль элементов или два и больше. Ноль даёт некорректный вызов.
-
Два и больше превращаются в пакет запросов, который никто не планировал оплачивать.
-
Решение занимает одну Code-ноду между триггером и запросом: она требует ровно один входной элемент и при любом другом числе останавливает сценарий с ошибкой. Принцип шире примера.
-
Если запрос стоит денег (платный API, отправка клиенту, списание), входные данные проверяются до него. С LLM это важнее вдвойне: модель отдаёт структуру, которая выглядит правдоподобно, и проверять её должен код. ###
-
Дубли и гонки В обсуждении салонной системы напоминаний и листа ожидания есть хороший ориентир.
-
Условный UPDATE сам является переходом состояния: `UPDATE slots SET state = 'Filled', phone = $1 WHERE slot_start = $2 AND state = 'Offered'` вернёт одну строку победителю и ноль остальным.
-
Статусы «забрал» и «опоздал» определяются по числу затронутых строк, отдельная логика для этого не нужна.
-
Тот же приём работает дальше по цепочке: переход «Забронировано → Напомнено»
-
выполняется, только если запись ещё в состоянии «Забронировано».
-
Два параллельных запуска больше не отправят клиенту два сообщения. ### Ошибки без оповещения
-
Сценарий без обработчика ошибок падает тихо, и о проблеме сообщает клиент, который не получил письмо или счёт. Retry без лимита даёт обратный эффект: сбойный вызов повторяется, пока не кончится квота.
-
Поэтому для workflow в продакшене нужно заранее задать таймаут, число попыток и получателя алерта.
