[magurotuna]

Fixes a race where void secret put during the first void deploy can take the new app offline.

What goes wrong

sequenceDiagram
  participant S as void secret put
  participant CF as Cloudflare
  participant D as void deploy (first)
  S->>CF: set secret
  D->>CF: deploy app
  CF-->>S: 10007 (no Worker yet, answered before the deploy)
  CF->>D: deploy success
  alt before this PR
    S->>CF: deploy empty placeholder
    Note over CF: app replaced by the placeholder
  else this PR
    S->>CF: create Worker if missing
    CF-->>S: 409 (already exists)
    S->>CF: set secret again
    Note over CF: app stays live, secret added
  end

Loading

• The site goes down and workers.dev is turned off, but both void secret put and void deploy print success.
• It needs a first deploy to finish within about two seconds of a first secret put (for example, CI deploying a new project while someone sets a secret). So it should be rare, but when this happens, it is silent and very mysterious.
• I reproduced it on a real account.

Fix

• The secret command creates the Worker with POST /workers/workers. Cloudflare answers 409 if the name is taken.
  • 200 (Created): it deploys the placeholder and the secrets in one request.
  • 409 (Conflict): it never deploys the placeholder and retries the secret command instead.

Additional Notes

• If a secret put fails right after creating the Worker (for example, the network drops), the Worker is left with no code. Later secret put runs then stop with steps to fix it, instead of deploying the placeholder on their own. Doing it automatically is unsafe: Void cannot tell this Worker from one that another secret put created a moment ago, and deploying the placeholder there would overwrite that command's secret. A small TLA+ model found this case.
• fix(cloudflare): stop on unsupported runtimes and keep deploy failures readable and safe #721 is related but different: it stops deploy recovery from rolling back to a placeholder.
• Tested against a real account: the race, secret-then-deploy, and the empty-Worker cases.

---

AI disclosure: I used Claude to write code and this PR. I reviewed them.

[cpojer]

fyi slop review:

P1: A second timing window still allows the placeholder to replace a deployed app. At line 1018, this sequence remains possible:

1. The secret command successfully creates the Worker.
2. A concurrent deploy publishes the real application.
3. The secret command uploads its placeholder with deploy=true, replacing the application and reporting success.

[cursor]

How to use the Graphite Merge Queue

Add the label graphite-auto-merge to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

[magurotuna]

@cpojer Yes, that race window remains, but it is much smaller.

• Before this PR, the deploy only had to publish between the 10007 and the placeholder deploy.
• Now its upload and publish both have to complete between the create and the placeholder deploy, which is a shorter window like under a second.

Cloudflare has no "deploy only if nothing is deployed" option. Closing this window fully would require a much bigger redesign around void deploy, which I decided not to do in this PR.

[cpojer]

Thanks for the explanation!