Temporal Activity ID Reuse Policy vs a Sume Idempotency-Key
Temporal's Activity ID Reuse Policy covers closed Standalone Activities; Sume's Idempotency-Key covers a retried submit. Why one does not replace the other.
Temporal's Activity ID Reuse Policy decides whether you can start a new Standalone Activity with the ID of one that already closed, and it protects nothing at Sume: a new Activity run is a new submit, and Sume dedupes only on the Idempotency-Key you send. If you use Allow Duplicate you can start the same business request twice, and each Activity must still pass the same Sume key if you want one job.
Temporal's options are from its Standalone Activity documentation, read 2026-10-03; the Sume rules are from Jobs and results and Errors and rate limits. How long Sume keeps an idempotency key is not stated in the pages I read, so I make no claim about a window.
What are the Temporal options?
For a closed execution within the retention period, the policy options are Allow Duplicate (the default), Allow Duplicate Failed Only and Reject Duplicate. A separate conflict policy applies while an execution with that ID is still running: Fail is the default, and Use Existing returns a handle to the running one.
| Temporal policy | What it does | Sume counterpart |
|---|---|---|
| Allow Duplicate (default) | A closed ID can be reused | A new Activity needs the same Idempotency-Key to return the original job |
| Allow Duplicate Failed Only | Reuse only after a failure | A failed job and a new submit are separate; decide on a new key on purpose |
| Reject Duplicate | A closed ID cannot be reused | Prevents a second Activity, not a duplicate submit inside one |
| Conflict policy Fail or Use Existing | Applies while an ID is running | Same key and body return the original job on retry |
Which one should I rely on?
Use both for different failures. The Temporal policy stops accidental duplicate Activities for the same business id. The Sume key stops a duplicate bill when one Activity retries its submit after a timeout. Sume's docs say to reuse a key only for the same operation and payload, and a changed payload under the same key returns 409 idempotency_conflict.
If a business request really should produce a new render after the first failed, give it a new key on purpose, and keep the failed job id so you can compare the two.
Sources
Related posts
More in Developers
- Temporal Standalone Activity Start Delay: a scheduled Sume submit
Start Delay holds only the first Activity Task; retries follow the Retry Policy. A delayed Sume submit needs one stable Idempotency-Key for every attempt.
- Tenacity retries forever with no wait: safe Sume submit
Tenacity's default is to retry forever without waiting. Four settings turn it into a bounded, jittered retry that is safe around a paid Sume submit.
- Test a language on Sume STT with a 30-second sample first
Vendors split languages into trained and verified. On Sume STT, language_code is a hint, so cut a 30-second sample and compare auto-detect with your hint.
- Test your Sume webhook receiver locally: openssl and curl
Sign a fake job.completed body with openssl, post it with curl and confirm your receiver answers 200 for valid, and 401 for stale and forged Sume deliveries.
Written by Sume