It has been almost 3 years since the same question has been “solved” (with a “we’re working on it”). What is the current status?
The only workaround I can think of is to create a machine with a special environment variable for the idempotency ID. But then, every time a machine is created, I’d have to fetch all the machines and check their environment variables, which seems like a real pain.
Is there a better way to do this now?
It depends on what your end goal is. Are you thinking of resource/cloud definitions like Terraform or Ansible? I am not aware of anything in the API for that, though one could do it oneself, by pulling the current definition and comparing with an intended definition.
The Create API contains this warning:
This request can fail, and you’re responsible for handling that failure.
To handle such failures, one must understand how to safely retry the request. Retries are even mentioned in the warning, but it’s unclear how to do so without risking the creation of more VMs than intended.
Idempotency should be table stakes IMO.
Oh, righto; I see what you mean now.
Wouldn’t you just have a loop, trying your regions in preference order, before an outright fail? I don’t see any scope for race conditions here; machine creation will either succeed or fail.
I’m a little unclear on why there’s emphasis on this, as well, but the 2022 post’s concern was avoiding an O(n) condition in the rare cases in which creation fails due to name collision.†
(And then @losfair, at least, wanted to go looking for the Machine ID corresponding to the already existing VM of that name.)
Currently, the response in that case does mention that Machine ID, but only within the freeform error message string:
{"error":"already_exists: unique machine name violation,
machine ID 7814669c299978 already exists with name \"dolphin\""}
@tomaso, I would parse the error message and then verify the name via a second, targeted call to the Machines API—but have a fallback that uses metadata. In particular, you can set "metadata": {"nom": "dolphin"} in the config, and then /machines?metadata.nom=dolphin will efficiently give you back that single VM.
(It would be nicer if the "error" field above had a companion "collided_with_id" field, of course, 
.)
†The platform prevents two Machines from having the same name, which achieves the primary “no more VMs than intended” intent. The missing piece (from their perspective) was an O(1) name → Machine ID lookup.
An idempotent key ensures that retries don’t cause duplicate resource creation.
When a client sends a request (e.g., to create a VM) and doesn’t get a response due to timeout or network issues, it can’t know if the server processed it. Retrying the request without an idempotent key risks creating duplicate resources.
@mayailurus I’ve re-checked the Create a Machine API and did not find the name parameter there, but turns out it works!
The name is the idempotent key I was looking for, so no need for listing all machines as I previously intended.