Does the Sume SDK retry a failed video submit? Only with a key

Will the Sume SDK retry a failed generation submit?

Only if you sent an Idempotency-Key. The client built by createSumeClient retries GET and HEAD requests on its own, and it retries any other method only when the request carries that header. Without a key, a failed POST is thrown to you after one attempt, because replaying it could start and charge a second job.

That default is the right one for video. A 30 second generation is paid work, and an ambiguous failure, such as a dropped connection after the server accepted the request, is exactly the case where a blind retry duplicates the spend. With a key, a replay of the same body returns the original job.

What gets retried and how

The retry count comes from maxRetries, which defaults to 2, and the wait between attempts uses backoff with random jitter so many clients do not retry in lockstep. When the server sends retry-after, the SDK honours it, capped at 60 seconds.

Submit with a key

Derive the key from something stable in your system, such as an order id, so that your own retry after a crash produces the same key. The generated operations resolve to { data, error, response } and do not throw, so check error yourself.

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

const client = createSumeClient({
  apiKey: process.env.SUME_API_KEY,
  maxRetries: 2,
});

export async function submit(orderId, prompt) {
  const { data, error, response } = await generateVideoV1({
    client,
    headers: { "idempotency-key": `order-${orderId}` },
    body: { prompt, mode: "async" },
  });
  if (error) {
    throw new Error(`submit failed (${response?.status}): ${JSON.stringify(error)}`);
  }
  return data.data.request_id;
}

console.log(await submit("1042", "Slow push-in on a ceramic mug"));

Limits of the built-in retry

Two retries with short backoff cover a blip, not an outage. For a 429 queue_full or a 503 provider_capacity_exceeded, wait longer in your own code and submit again with the same key. A different body with the same key is a 409 idempotency_conflict, and the SDK will not retry that, which is what you want.

Keep the key alive as long as you might retry. Store it with the order, and if you change the request on purpose, mint a new key so the change is a new job and not a conflict.