Repository navigation
fix(deploy): resolve the workers.dev URL after a first publish over a draft Worker - #641
Merged
cpojer merged 4 commits intoOct 30, 2026
Merged
Conversation
magurotuna
marked this pull request as ready for review
October 30, 2026 04:06
… draft Worker
`void secret put` creates a draft Worker with workers.dev disabled. The
next first deploy publishes through the pinned version upload, which
reports a version id but no URL. Without a configured or cached account
subdomain, `bootstrapFirstDeployment` returned `atomic-output-invalid`
or `bootstrap-output-invalid` after the version was live, so trigger
synchronization and the readiness check never ran.
If the publish reports no URL and the desired config enables
workers.dev, Void now checks the pinned uploader and reads the account
subdomain from `GET /accounts/{account_id}/workers/subdomain`. It then
continues to trigger synchronization and readiness on the resolved URL.
If the lookup fails, the old result remains. The error message now
names the live version and points to `CLOUDFLARE_WORKERS_SUBDOMAIN`
when only the URL is missing.
Fixes voidzero-dev#573
- Add the `.fed` label to the looked-up subdomain for FedRAMP High, as Wrangler does. The lookup resolves the compliance region with the same rules as the pinned API base. Before this change, readiness and its Access headers went to the public-region host. - Return a `CloudflareWorkersDevSubdomainLookup` result from the lookup. A changed uploader inside the lookup now gives `uploader-changed` with `rollback: 'unsafe'`, not an unknown-URL error. - Skip the lookup when trigger synchronization does not publish `workers_dev`, because a preserved snapshot leaves workers.dev off. - For a non-atomic first deploy, tell the user to turn on workers.dev in the dashboard before they retry. Show the FedRAMP High subdomain form. - Add tests for the region suffix, the CLI wiring, the guards, and the published trigger config.
Pin the workers.dev compliance region with the API base, before project code runs, and pass it to the lookup. The lookup no longer reads the root config again after the build, so a build cannot change the host that receives the Access readiness headers. If the region does not resolve (a direct API base with an invalid or conflicting region), the lookup reports no URL instead of guessing a host. Add a test for the usual CLI message, which preserves unset traffic settings. Split the bootstrap recovery line into two sentences.
cpojer
force-pushed
the
fix/573-atomic-publish-no-url
branch
from
October 30, 2026 07:43
d88eba9 to
dc7c7a1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #573
Problem
If you run
void secret putorvoid secret syncbefore the firstvoid deploy, the deploy fails withatomic-output-invalid(orbootstrap-output-invalidin the non-atomic mode). The new version is already live, but workers.dev stays disabled, and the readiness check never runs.The secret commands create a draft Worker because Cloudflare stores secrets on a Worker. The draft has workers.dev disabled. Cloudflare does not return a URL when it publishes over this draft. Void needs the account subdomain to build the readiness URL, but a first deploy has no configured or cached subdomain. Void enables workers.dev later, in the trigger sync, so the deploy stops before workers.dev is ever enabled.
What changed
If the publish returns no URL, Void asks Cloudflare for the account subdomain and continues. Some points that the code does not show:
compliance_regionand send the probe to a different host. For FedRAMP High, the host gets.fed, as in Wrangler.The lookup needs no paid product, so Workers Free deploys still work. The docs do not change.
Tests
The tests mock Cloudflare. The issue scenario (a draft Worker, and a publish with no URL) failed before the fix in both modes and passes after it. Other tests cover the cases that must skip the lookup, the FedRAMP host, the region pin, and a changed uploader.
Choices to check
urlslist (as the issue reports), and that the subdomain endpoint returns the label without the region suffix (as Wrangler assumes).CLOUDFLARE_WORKERS_SUBDOMAIN. I did not add the lookup there, because it changes which host receives Access credentials. That belongs in a separate PR.AI disclosure: I used Claude to write code and this PR. I reviewed them.