Temporal Activity ID Reuse Policy vs a Sume Idempotency-Key

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.

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.