Before You Retry a 429 in n8n: 6 Retry-After Cases I Tested

Описание и применение

В n8n встроенный механизм повторных попыток игнорирует заголовок Retry-After и может повторять небезопасные запросы. Автоматический рецепт, описанный в статье, учитывает различные варианты Retry-After, добавляет случайный jitter, ограничивает длительные ожидания и откладывает небезопасные операции, обеспечивая безопасную и предсказуемую логику повторов.

Задача

Blind retry logic in n8n ignores API-provided wait times and can repeat unsafe work.

Результат

All 18 policy checks passed in an offline lab; policy correctly handles various Retry-After scenarios and unsafe writes.

Рабочий процесс

• 1. Enable Retry On Fail in n8n.
• 2. Add a safety flag to mark requests safe to repeat.
• 3. On HTTP 429, check Retry-After header: if seconds, wait header+random up to 1s; if HTTP date, compute wait from date; if past, wait at least 1s; if missing/garbled, use exponential backoff starting 2s capped 60s.
• 4. If Retry-After exceeds 300s, defer job instead of blocking execution.
• 5. If request is not safe to repeat, send to review and do not retry automatically.
• 6. Allow maximum 4 attempts total (including first).

Доказательства

Turning on Retry On Fail in n8n feels like a fix. It waits a fixed time and tries again.

Источник

I built a small offline lab to check what a safer retry policy should do. The HTTP responses in it are simulated, so this is a test of the decision logic, not of a live API.

Источник

Four attempts in total, including the first. Only HTTP 429 is retried. A request is retried only if the job is marked safe to repeat.

Источник

If your retries behave differently from what the lab expects, I would like to hear which case broke.

Источник