[wrangler] Widen agent Pages-to-Workers delegation for new projects - #15004
Open
MattieTK wants to merge 3 commits into
Open
[wrangler] Widen agent Pages-to-Workers delegation for new projects#15004MattieTK wants to merge 3 commits into
MattieTK wants to merge 3 commits into
Conversation
A --branch (deploy) or --production-branch (project create) flag no longer disqualifies an agent command from Pages-to-Workers delegation. Delegation only fires for a brand-new project, where a branch flag merely names the production branch — exactly what a Workers deploy targets — so there are no preview-deployment semantics to preserve. Genuinely Pages-only flags (--commit-*, --skip-caching) still disqualify a deploy. (cherry picked from commit 26d0988)
🦋 Changeset detectedLatest commit: 56f973d The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
workers-devprod
requested review from
a team and
dario-piotrowicz
and removed request for
a team
August 3, 2026 18:10
Contributor
|
Codeowners approval required for this PR:
Show detailed file reviewers |
Contributor
|
✅ All changesets look good |
Contributor
|
These tests run in a non-agent environment (no agent mocked), so delegation short-circuits at the I've completed a thorough review:
The only minor observations (test-coverage gap for the LGTM |
@cloudflare/autoconfig
@cloudflare/build-output-utils
@cloudflare/config
create-cloudflare
@cloudflare/deploy-helpers
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-functions
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-auth
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
commit: |
MattieTK
changed the title
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
…r-account Replace the per-account `accountHasPagesProjects` check with a per-project `projectExists` gate, so an agent deploying or creating a brand-new static Pages project is delegated to a Workers static-assets deploy even when the account already has other Pages projects. A command targeting a project that already exists stays on Pages: `pages deploy` reuses the existence lookup it already performs, and `pages project create` resolves it lazily (agents only) so a name clash is left on Pages instead of being deployed to Workers under that name.
MattieTK
force-pushed
the
fix/pages-delegation-branch-flags
branch
from
August 3, 2026 23:38
58cb354 to
b72720f
Compare
dario-piotrowicz
approved these changes
Aug 4, 2026
dario-piotrowicz
left a comment
dario-piotrowicz
left a comment
Member
There was a problem hiding this comment.
LGTM with a minor nit
Comment on lines
+100
to
+107
| /** | ||
| * Whether a Pages project with the given name already exists on the account. | ||
| * | ||
| * Returns false for a missing name or a not-found project; any other API error | ||
| * propagates so the caller can decide how to treat a failed lookup (the | ||
| * delegation gate skips delegation rather than risk delegating over a project | ||
| * that may already exist). | ||
| */ |
Member
There was a problem hiding this comment.
nit: personally I love using @params and @returns as they make the comment more readable and clear
workers-devprod
approved these changes
Aug 4, 2026
workers-devprod
left a comment
workers-devprod
left a comment
Contributor
There was a problem hiding this comment.
Codeowners reviews satisfied
Convert the pagesProjectExists and getUnsupportedDeployDelegateArgs doc comments to @param/@returns/@throws form for readability, per review feedback. Comment-only; no behaviour change.
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
3 participants
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.
Two related changes that widen the agent Pages-to-Workers delegation so the common "brand-new static project" case lands on Workers instead of falling through to a direct Pages deploy. Both remain agent-only.
Branch flags no longer disqualify delegation
wrangler pages deploy --branch <name>andwrangler pages project create --production-branch <name>are now eligible for delegation. A branch flag was implicitly treated as evidence that an established Pages project already existed, so its presence bypassed delegation. But delegation only ever fires for a brand-new project, where a branch flag merely names the production branch – exactly what a Workers static-assets deploy targets. There are no preview-deployment semantics to preserve, so the flag no longer needs to disqualify the command. Genuinely Pages-only flags (--commit-hash,--commit-message,--commit-dirty,--skip-caching) still disqualify a deploy.Per-project delegation gate
The gate is now per-project rather than per-account. Previously an account that already had any Pages project was never delegated; now a brand-new project is delegated even when the account has other Pages projects, while a deploy to an existing project stays on Pages. This also drops the paginated list-projects API call from the delegation path in favour of the project-existence signal the deploy command already computes.
The experimental rationale telemetry and the opt-out-flag rename from the same research branch are intentionally not included here.