Nomad Reschedule Stanza and Task Writes: Where Should Idempotency Live?

A Nomad job specification separates two re-execution paths. The restart stanza governs task-level exits inside an existing allocation, while the reschedule stanza governs replacement of an allocation after node loss or drain. Both control when a task process runs again; neither is documented to inject a scheduler-generated idempotency key into the work the task performs.

The design goal is a job, assumed to be Nomad 1.x, whose task writes to an external datastore and must not create duplicate records when the task is re-run. The constraint is that the write path has to supply whatever uniqueness the datastore enforces, because the scheduler only decides when the process starts.

What remains unclear is which Nomad-provided values stay stable across a restart versus a reschedule, and whether that stability is documented per version. Stanza fields and defaults have differed across Nomad 1.x releases, so the reference for the version in use matters.

• Across a restart and a reschedule, which Nomad-provided values remain stable enough to key a task's write?
• Is there a documented Nomad mechanism intended to cover duplicate writes, or does that responsibility sit entirely in the task's application code?