Repository navigation
fix(deploy): bypass deployment checks for automatic rollbacks - #571
Open
davidgustys wants to merge 1 commit into
Open
davidgustys wants to merge 1 commit into
davidgustys wants to merge 1 commit into
Conversation
Cloudflare rejects a deployment that rolls back to an older version after a secret changed (error 10220) unless it is forced. Void's automatic recovery after failed readiness, activation or trigger synchronization therefore failed whenever the failed version changed a secret, leaving the Worker at previous@100 plus failed@0 and blocking later deploys with deployment-changed. Add an optional bypassDeploymentChecks flag to versions.deploy, mapped to cf's --bypass-deployment-checks (force=true), and set it only on automatic recovery paths that have already verified ownership of current traffic: restorePreviousVersion, the trigger-synchronization rollback, and platform deployment restoration. Normal deploys and user-requested rollbacks are unchanged.
davidgustys
force-pushed
the
fix/rollback-bypass-deployment-checks
branch
from
October 23, 2026 13:05
058c950 to
c16802d
Compare
This branch has not been deployed
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.
Cloudflare refuses a deployment that moves traffic back to an older Worker version when a secret has changed since that version was active (error 10220), unless the request is forced. Void's automatic recovery runs into this. After a failed readiness check, activation or trigger sync, it deploys the previous version at 100%. Cloudflare rejects that, the Worker stays at the previous version at 100% plus the failed one at 0%, and the next deploy stops with
deployment-changeduntil the deployment is fixed by hand.This adds an optional
bypassDeploymentChecksto theversions.deployoperation. It is passed to cf as--bypass-deployment-checks, which sendsforce=trueto the Deployments API. Only automatic recovery sets it, and only after the existing check that Void still owns the current traffic:restorePreviousVersion, for readiness, activation and trigger-sync failuresactivateCloudflareExistingVersionrestorePlatformWorkerDeploymentin the platform installerNormal deploys and user-requested rollbacks are unchanged.
It applies when the version being rolled back from changed a secret. In stock Void, that's
void platform upgradewith a replacementVOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN: the new token is uploaded with the new version, so a failed trigger publish can't restore the previous deployment. I found it in a fork that publishes prebuilt artifacts with explicit secrets. There, a deploy that changed a secret and then failed readiness left the Worker stuck as described. With this change, the same live run on Cloudflare restored the previous version and the next deploy went through.?force=trueis sent alongside the deployment body.vp run check,vp fmt,vp lint,vp run test --base mainand one fullvp test run. The only failing files are theinit,init-installandnitrotests, which fail the same way onmainlocally.