Sume SDK maxRetries: 0 when your job queue already retries the call

The SDK retries 408, 429 and 5xx twice by default. Under a queue with five attempts that is up to 15 tries. Set maxRetries to 0 and let one layer retry.

4 min readSume
All posts

createSumeClient in @sume-com/sdk retries by default: maxRetries is 2, so one logical call can make three HTTP attempts. It retries 408, 429, 5xx and transport failures, honors retry-after up to 60 seconds, and adds roughly 20% jitter. POSTs retry only when an Idempotency-Key is present.

Put that client inside a job queue that retries on its own and the attempts multiply. A worker that retries five times, each making three attempts, hits the API up to 15 times for one failing job, and every extra 429 makes the next one likelier.

The multiplication

Attempts per failing call, from the SDK defaults, read 2026-10-06
SDK maxRetriesQueue attemptsWorst-case HTTP tries per job
2 (default)13
2 (default)515
055

Pick one retry owner

Setting maxRetries: 0 is the simple choice when the queue already has backoff, a dead-letter path and metrics. The handler then throws on a failed job and the queue decides.

import { createSumeClient, waitForJob } from "@sume-com/sdk";

// SDK default is maxRetries: 2, so one call can make 3 HTTP attempts. Behind a
// queue that retries 5 times, one flaky 5xx can turn into 15 attempts.
const client = createSumeClient({
  apiKey: process.env.SUME_API_KEY!,
  maxRetries: 0, // the queue owns the retry policy
});

export async function handler(job: { data: { jobId: string } }) {
  const done = await waitForJob(job.data.jobId, { client, timeout: 60_000 });
  if (done.status !== "completed") {
    throw new Error(`job ended ${done.status}`); // the queue decides whether to retry
  }
  return done.status;
}

When to leave the default

  • A script with no queue benefits from the SDK retry and its retry-after handling.
  • If you do turn retries off, keep sending an Idempotency-Key on every POST so your queue's retry cannot create a second run.
  • Your queue's backoff should respect retry-after as well, or you will retry sooner than the server asked.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume