Temporal Standalone Activity Start Delay: a scheduled Sume submit

For a Temporal Standalone Activity that submits a Sume job later, such as a reminder video that should start tomorrow, use Start Delay for the wait and one fixed Idempotency-Key for the submit, because Temporal's documentation says the delay applies to the first Activity Task only and retries are dispatched by the Retry Policy, not the delay. A retry therefore reaches Sume immediately and with the same payload, which is the case Sume's idempotency is for.

Temporal's behavior is from its Standalone Activity documentation, read 2026-10-03; Sume's from Jobs and results and Errors and rate limits. I did not run a Standalone Activity against Sume.

What does the delay cover?

The docs describe Start Delay as scheduling a job to begin after a waiting period, for deferred work like reminder emails without creating a recurring schedule. The delay is for the first task. After a failed attempt, the Retry Policy decides when the next one runs, so a transient 503 from Sume or a worker restart does not wait another full delay.

The activity also has the usual timeouts, Schedule-To-Start, Start-To-Close, Schedule-To-Close and Heartbeat. I did not verify from the page whether the start delay counts against Schedule-To-Start, so check that before setting a short one.

What should the key be built from?

Build it from the Activity ID or from a business id you set once at start, for example the customer id and the occasion, and keep any value that changes per attempt out of the body. Sume's rule is to reuse a key only for the same operation and payload; a prompt that embeds a timestamp generated inside the retried activity would change the payload and return 409 idempotency_conflict instead of the original job.

After the submit, the activity should not hold the whole render open. Store the job_id, then poll status_url honoring next_poll_after_seconds, or use webhook mode, and read the result when result_ready is true.