Harpy → Retry & Backoff

Retry & Backoff

Harpy retries failed requests automatically using exponential backoff — configure the attempt limit once and get resilience for free.

How it works

On a 5xx response or a connection error, Harpy waits and retries automatically before giving up. The default maximum is 3 retries (4 total attempts):

AttemptWait before retry
1 (first try)
21 s
32 s
4 (default max)4 s

Each wait doubles the previous one (exponential backoff). After the final attempt fails, the error is delivered to your callback or Promise reject handler.

What triggers a retry

ConditionRetried?
5xx response (500, 502, 503, 504 …)Yes
Connection error (network timeout, DNS failure)Yes
4xx response (400, 401, 403, 404 …)No — returned immediately
2xx responseNo — resolves immediately

4xx responses are client errors and are returned immediately without retrying — retrying a 401 or 404 would not help.

Configuration

Set retries in the constructor or call :SetRetries at any time:

Harpy.New({ retries = n })
harpy:SetRetries(n)
-- Conservative client: 5 retries
local safeClient = Harpy.New({
    base    = "https://critical-api.example.com",
    retries = 5,
})

-- Webhook: only 1 retry, don't want to spam
local webhook = Harpy.New({
    base    = DISCORD_WEBHOOK_URL,
    retries = 1,
})

Disabling retries

Pass retries = 0 to make Harpy fail immediately on any error without retrying:

local client = Harpy.New({ base = "https://api.example.com", retries = 0 })

-- Or update an existing client
client:SetRetries(0)
Retry count is per-client. A fire-and-forget webhook usually needs fewer retries than a score-submission client that must not lose data.

See also

← Harpy  ·  Configuration | constructor and runtime methods  ·  HTTP Methods | Get, Post, Put, Delete