Temporal Maximum Attempts 1 and a paid Sume submit

Standalone Activities default to at-least-once retries. Maximum Attempts 1 gives at-most-once, but a Sume Idempotency-Key lets you keep retries safely.

4 min readSume
All posts

Use the Sume Idempotency-Key header and keep Temporal's default retries. Setting Maximum Attempts to 1 makes a Standalone Activity at-most-once, which also means one dropped connection loses a submit you could have retried for free.

Temporal facts are from its Standalone Activity docs and the Server v1.32.0 release page; Sume facts are from Communication modes and Errors and credits. All read 2026-10-01.

What did Temporal change?

The v1.32.0 release notes say Standalone Activities are enabled by default on the server, with delayed starts, operator APIs and batch operations. The docs describe them as top-level Activity Executions started by a Client with no Workflow, so there is no Event History and no deterministic replay. The docs say they are generally available in Temporal Cloud and need CLI v1.9.1+ and Server v1.32.0+.

What does a retry do to a paid submit?

Per the docs, the default retry policy retries with exponential backoff until the activity succeeds or Schedule-To-Close expires, so execution is at-least-once. Setting Maximum Attempts to 1 gives at-most-once. The docs also state that activity code must be idempotent.

A Sume submit is paid, so it is the call that most needs that property. If the first attempt reached Sume but the response never reached your worker, a plain retry would be a second job.

Retry setting versus Sume submit outcome, from the Temporal docs and Sume docs read 2026-10-01
SettingTemporal behavior (docs)Effect on the Sume submit
Default retriesAt-least-once until success or Schedule-To-CloseSafe only with an Idempotency-Key
Maximum Attempts 1At-most-onceA lost response is a lost submit
Same key, same payloadNot applicableSume returns the original job instead of billing twice
Same key, different payloadNot applicable409 idempotency_conflict

How do you make the submit activity idempotent?

Derive the key from your own business id, not from a random value generated inside the activity, so every attempt sends the same key. Reuse a key only for the same operation and payload; a different payload under the same key returns 409 idempotency_conflict.

Throw on any error so Temporal retries, and keep the call to a submit with mode: "async". The result comes from a separate poll or a webhook, not from this activity.

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

const client = createSumeClient({ apiKey: process.env.SUME_API_KEY! });

// `key` must be the same on every attempt of the same logical submit.
export async function submitVideo(prompt: string, key: string) {
  const { data, error } = await generateVideoV1({
    client,
    headers: { "idempotency-key": key },
    body: { prompt, mode: "async" },
  });
  if (error) throw new Error(JSON.stringify(error));
  return data!.data.request_id;
}

Where does polling belong?

Poll GET /v1/jobs/{id}/status and honor next_poll_after_seconds. A client-side timeout does not cancel the job and it still bills, so store the job id before you wait. See how to cancel from Temporal when you need to stop one.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume