Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Honour the Worker name selected by Workers Builds for production and Preview deployments

Open
  • Is something wrong?
#307 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
22/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript, vite
Domain
ci-cd, cli, cloud

Research direction

Start in packages/cli/src/commands/deploy/shared.ts (production upload of the selected Worker) and packages/cli/src/commands/previews/deploy.ts (Preview Build Output), and read getCIOverrideName in @cloudflare/workers-utils plus resolveWorkerName in deploy-helpers for the precedence rules. Done when WRANGLER_CI_OVERRIDE_NAME sets the target name in both normal and --prebuilt paths, mismatched names deploy to the connected parent Worker, and the skipped override cases in the unported-07 and unported-04 test catalogues are covered.

Written by the indexing model from the issue text.

Description

Summary of the issue

cf does not honour the Worker name selected by Workers Builds when it differs from worker.name in cloudflare.config.ts. Builds supplies the selected name through WRANGLER_CI_OVERRIDE_NAME, but the tested production and native Preview deployment paths still use the configured name.

This prevents reliably connecting an existing project or template to a differently named dashboard Worker. More seriously, a native Preview build can report success while deploying a Preview under the wrong parent Worker.

Expected behaviour

For deployments run by Workers Builds, use WRANGLER_CI_OVERRIDE_NAME as the target name of the selected Worker, including when deploying existing Build Output. Both production deployments and native Previews should remain attached to the Worker connected to Builds, even when the source configuration has a different name.

Preserve preview-aware configuration (isPreview: true), Preview names, and normal configured names outside Builds. In multi-Worker output, apply the override to the selected deployment target, not every Worker. A job connected to Worker A should not redirect its deployment to Worker B merely because the configuration changes its name.

Version of cf used

1.0.0-beta.17

System information and package versions

Verified on October 14, 2026 using real hosted Workers Builds, triggered by pushes to a disposable Cloudflare Artifacts repository:

  • Node: 24.18.0
  • npm: 10.9.2
  • @cloudflare/vite-plugin: 2.0.0-beta.sha-67fa336fd
  • Vite: 8.3.4
  • Configuration: cloudflare.config.ts; no Wrangler configuration file.

Reproduction

  1. Connect a simple cf/Vite Worker project to a dashboard Worker named dashboard-worker.
  2. Start with worker.name: "dashboard-worker" in cloudflare.config.ts.
  3. Configure production Builds with build command npx cf build and deploy command npx cf deploy --prebuilt --no-provision.
  4. Enable native Worker Previews, with no separate build command and deploy command npx cf previews deploy. This command performs its own preview-aware build.
  5. Push the matching-name configuration to the production branch and a Preview branch. Both runs succeed, and the Preview ID returned by cf matches the allocation tracked by Builds.
  6. Change only worker.name to config-worker, leaving the dashboard connection and build settings unchanged. Push to the production branch and a new Preview branch.
Observed results
Configuration Production Native Preview
Config name matches connected Worker Success Success; expected Preview ID
Config name differs from connected Worker Compilation succeeds; deployment fails Reports success, but deploys under the config-named parent Worker

The mismatch production run fails because the config-named Worker does not exist. The matching production deployment remains active.

The mismatch Preview run creates a parent Worker record for the config name and deploys a Preview under it. Its returned Preview ID differs from the one allocated by Builds for that branch. This is not a second production deployment: the new parent's deployed_on is null.

Relevant error logs

Names below are simplified; account identifiers and application URLs are omitted.

The Preview configuration callback logs show that Builds supplies the correct override and cf performs a preview-aware build:

{
  "configuredName": "config-worker",
  "buildsSelectedName": "dashboard-worker",
  "isPreview": true,
  "mode": "production"
}

The production deployment fails with:

The Worker "config-worker" was not found in your account. Check that the name in your wrangler.json file is correct and that the Worker exists in this account.

The wrangler.json reference is misleading for a cf-config project.

Existing implementation to reuse

Wrangler already supports the Builds name override. Shared workers-sdk code also contains relevant helpers:

Suggested integration points are cf's selected-Worker production upload path in packages/cli/src/commands/deploy/shared.ts and Preview Build Output path in packages/cli/src/commands/previews/deploy.ts. Ensure both normal and --prebuilt deployment paths use the selected target consistently. The exact integration should account for dependent bindings and multi-Worker output rather than blanket-renaming configuration.

Acceptance coverage should include matching names, mismatched names, ordinary and prebuilt deployments, the parent Worker and returned Preview identity, unchanged behaviour without an override, and no unintended renaming of other Workers.

This is separate from #185 / #288, which concern writing deployment result metadata so Builds can display the Preview URL. Reporting a URL does not fix deployment to the wrong parent Worker.

Dominant language
TypeScript
Stars
916
Forks
53
Avg merge
19h 13m
Merged PRs (30d)
185

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cloudflare/cf

All issues in cloudflare/cf

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.