Вузол n8n Wait: обробка повторних спроб та API з обмеженням швидкості
Практичний огляд вузла n8n Wait: пауза воркфлоу перед API з лімітом швидкості, збереження даних і повторні спроби з backoff.
Перевірено за наведеними джерелами .
Передумови та мета: призупинення воркфлоу з обмеженням швидкості
Якщо воркфлоу, який ви створюєте, викликає API з обмеженням швидкості (rate limit), вузол n8n Wait дозволяє призупинити виконання і продовжити пізніше з тими самими даними, що були в обробці, замість втрати елементів, які ви вже частково обробили. Цей туторіал припускає, що у вас уже є воркфлоу n8n, який викликає зовнішній API через вузол HTTP Request, і що цей API іноді відповідає повільно, просить сповільнитися або повертає помилку обмеження швидкості.
- Воркфлоу n8n із вузлом HTTP Request, що викликає API з обмеженням швидкості
- Можливість додати та налаштувати вузол Wait у цьому воркфлоу
- Розуміння того, як API сигналізує про обмеження швидкості, наприклад статусом 429 або заголовком Retry-After
Основна ідея проста. Офіційна документація n8n описує очікування як спосіб призупинити воркфлоу посеред виконання і відновити роботу з того ж місця, з тими самими даними, що корисно для регулювання темпу викликів до сервісу з обмеженням швидкості або очікування зовнішньої події перед продовженням (F4). Щоб зробити цю паузу безпечною, n8n вивантажує дані виконання, що обробляються, у свою базу даних, поки воркфлоу очікує, а потім завантажує їх назад, коли воркфлоу відновлюється (F2).
Цей туторіал поєднує вузол Wait із Retry On Fail, Loop Over Items та воркфлоу Error Trigger в одну цілісну схему. Жодне з використаних тут джерел не показує все це поєднаним в одному наскрізному прикладі; ця комбінація — власний синтез цього туторіалу з окремих сторінок офіційної документації, а не задокументований еталонний воркфлоу.
Sources: Wait | Build | n8n Docs, Wait | Nodes | n8n Docs
Кроки 1 і 2: налаштування вузла n8n Wait і регулювання темпу запитів за допомогою Loop Over Items
Почніть із додавання вузла n8n Wait після виклику, темп якого потрібно регулювати. Вузол підтримує чотири умови відновлення: після фіксованого проміжку часу, у визначений час, за вхідним викликом webhook або за надсиланням форми (F1). Для регулювання темпу викликів до API з обмеженням швидкості After Time Interval зазвичай є найпростішим варіантом, оскільки ви безпосередньо контролюєте затримку, а не чекаєте на зовнішній тригер.
| Режим відновлення | Що запускає відновлення | Типове використання |
|---|---|---|
| Після проміжку часу (After Time Interval) | Минув заданий фіксований проміжок часу | Регулювання темпу викликів до API з обмеженням швидкості |
| У визначений час (At a Specified Time) | Годинник досягає обраної дати й часу | Планування відновлення на відомий момент у майбутньому |
| За викликом webhook (On Webhook Call) | Зовнішня система викликає згенерований URL webhook | Очікування сигналу готовності від іншої системи |
| За надсиланням форми (On Form Submitted) | Хтось надсилає пов'язану форму n8n | Очікування, поки людина надасть дані |
Для списку елементів, які потрібно надсилати по одному, документація n8n описує поєднання вузла Loop Over Items із вузлом Wait: розбийте вхідні елементи на пакети за допомогою Loop Over Items, виконайте виклик API, а потім розмістіть після нього вузол Wait, щоб цикл робив паузу між запитами замість того, щоб надсилати їх усі одразу (F10). Це зберігає дані кожної ітерації незмінними, оскільки саме воркфлоу, а не окремий скрипт, утримує стан циклу під час очікування.
Ще одна деталь, яку варто знати, перш ніж покладатися на дуже короткі паузи: n8n не вивантажує дані виконання в базу даних для очікувань коротших за 65 секунд, натомість тримаючи процес у пам'яті, поки не мине інтервал (F3). Для поодиноких коротких пауз це непомітно; документація не описує, як це поводиться при великій кількості одночасних коротких очікувань, тож масове накопичення коротких пауз варто розглядати як неперевірену територію, яку слід тестувати у власному середовищі, а не як гарантовано безпечний патерн.
Побудова воркфлоу з повторними спробами та затримками
- Додайте вузол Wait: Розмістіть його після виклику API та оберіть умову відновлення, що відповідає ситуації.
- Регулюйте темп за допомогою Loop Over Items: Розбийте елементи на пакети та розмістіть вузол Wait усередині циклу, щоб розділити запити в часі.
- Увімкніть Retry On Fail: Дозвольте вузлу самостійно робити короткі повторні спроби з паузою між ними.
- Створіть власний цикл Wait: Спрямовуйте помилки у вузол Wait і назад для затримок, довших за ті, що дозволяє вбудований повтор.
- Приєднайте воркфлоу Error Trigger: Ловіть вичерпані повторні спроби, коли власний цикл здається.
- Дотримуйтеся Retry-After: Використовуйте власний сигнал API для встановлення тривалості очікування замість вгадування.
Sources: Wait | Nodes | n8n Docs, Handle rate limits | Nodes | n8n Docs
Кроки 3 і 4: автоматичний Retry On Fail проти власного циклу backoff на вузлі Wait
Для коротких повторних спроб на рівні вузла увімкніть Retry On Fail на вузлі HTTP Request. Документація n8n описує це налаштування як додавання паузи між автоматичними повторними спробами — це один із вбудованих способів обробляти обмеження швидкості без побудови додаткової логіки (F9). Спробуйте це спочатку, перш ніж звертатися до власного циклу, адже воно не потребує додаткових вузлів.
У Retry On Fail є стеля. Учасник форуму спільноти описує вбудоване очікування повторної спроби вузла як обмежене приблизно 5000 мілісекундами, і обходить це обмеження, спрямовуючи вихід помилки вузла в окремий вузол Wait, налаштований на потрібну довшу затримку, а потім повертаючи потік назад у той самий вузол (F12). Це свідчення одного учасника з форуму, а не задокументована поведінка n8n, тож точне значення обмеження варто вважати неперевіреним і протестувати у власному воркфлоу, перш ніж на нього покладатися.
- З'єднайте вихід помилки вузла з новим вузлом Wait замість того, щоб дати воркфлоу завершитися з помилкою
- Встановіть у цьому вузлі Wait тривалість, яка вам справді потрібна
- Спрямуйте вихід вузла Wait назад у початковий вузол, що викликає API
- Обмежте кількість проходів циклу, щоб постійно неуспішний виклик зрештою припиняв повторні спроби
Схожа ідея, викладена в особистому блозі, замінює єдину фіксовану тривалість Wait на динамічно обчислювану, засновану на власному сигналі retry-after від API та кривій backoff, що подовжується з кожною спробою, замість того щоб завжди чекати однаковий час (F11). Ця публікація також рекламує платний шаблон воркфлоу, а її технічні деталі не підтверджені офіційною документацією n8n, тож варто сприймати це як патерн для адаптації й перевірки, а не як перевірений рецепт.
Sources: Handle rate limits | Nodes | n8n Docs, Every node: Retry on fail > max. 5000ms > why? - Questions - n8n Community, How I Ended Up Building a Stable Async Processor for n8n (and Turned It Into a PRO Tempate) - DEV Community
Кроки 5 і 6: перехоплення вичерпаних повторних спроб і дотримання Retry-After
Коли ваш власний цикл Wait зробив стільки повторних спроб, скільки ви дозволили, передайте помилку воркфлоу обробки помилок, а не дайте їй просто зникнути. Воркфлоу обробки помилок обов'язково починається з вузла Error Trigger, і той самий воркфлоу обробки помилок можна повторно використовувати в кількох воркфлоу (F7). Пам'ятайте, що Error Trigger спрацьовує лише для автоматично виконаних воркфлоу, а не для ручних тестових запусків, тож перевірити цей шлях просто натиснувши "Execute Workflow" не вийде (F5). Щоб перевірити це навмисно, додайте вузол Stop And Error за тестової умови; він змушує воркфлоу завершитися з помилкою та навмисно запускає пов'язаний воркфлоу обробки помилок (F8).
- Починайте воркфлоу обробки помилок із вузла Error Trigger, який можна повторно використовувати в кількох воркфлоу
- Пам'ятайте, що Error Trigger запускають автоматичні виконання, а не ручні тестові запуски
- Спричиніть навмисну помилку за допомогою вузла Stop And Error, щоб переконатися, що воркфлоу обробки помилок справді спрацьовує
Одна взаємодія не висвітлена в джерелах, використаних тут: як поводиться відновлення вузла Wait, якщо в тому самому воркфлоу одночасно активний вузол Error Trigger або Stop And Error. Це не задокументовано на офіційних сторінках, на які спирається цей туторіал, тож ретельно протестуйте свою конкретну комбінацію вузлів Wait та обробки помилок, перш ніж покладатися на неї у продакшені.
Коли ваш воркфлоу обробки помилок отримує дані про помилку, вони містять поле retryOf, яке присутнє лише тоді, коли повідомлене виконання саме було повторною спробою попереднього невдалого виконання, — це корисний контекст для розрізнення першої помилки та вичерпаного ланцюга повторних спроб (F6).
Насамкінець, не вгадуйте тривалість очікування, коли API сам підказує, що робити. Власні рекомендації n8n радять, щоб після відповіді 429 воркфлоу зчитував заголовки відповіді API та використовував будь-яке значення Retry-After, щоб визначити, скільки чекати перед новою спробою, замість негайного повтору чи повтору за фіксованим графіком (F13). Передайте це значення в тривалість вашого вузла Wait, щоб темп запитів відповідав власному сигналу API, а не довільному припущенню.
Sources: Handle errors gracefully | Build | n8n Docs, Error Trigger | Nodes | n8n Docs, A Guide to API Rate Limiting for More Reliable Workflows – n8n Blog
Очікувані результати та усунення несправностей вузла n8n Wait
З таким налаштуванням воркфлоу, що викликає API з обмеженням швидкості, має чисто призупинятися на кожному вузлі n8n Wait, зберігати незмінними елементи, що обробляються, оскільки n8n вивантажує дані виконання у свою базу даних під час очікування (F2), і автоматично відновлюватися, щойно настане налаштований вами інтервал, час, виклик webhook чи надсилання форми (F1). Повторні спроби, що перевищують ваші вбудовані ліміти, повинні потрапляти у ваш воркфлоу обробки помилок із достатнім контекстом, включно з полем retryOf, щоб відрізнити нову помилку від вичерпаного ланцюга повторних спроб (F6).
Коротке очікування, що відновлюється майже миттєво, — це очікувана поведінка, а не помилка (F3). Якщо здається, що ваш воркфлоу обробки помилок під час тестування взагалі не запускається, це, ймовірно, обмеження ручного запуску, вже описане в Кроках 5 і 6, а не проблема налаштування (F5).
Sources: Wait | Nodes | n8n Docs, Error Trigger | Nodes | n8n Docs, Handle errors gracefully | Build | n8n Docs, A Guide to API Rate Limiting for More Reliable Workflows – n8n Blog
