Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#307 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
22/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript, vite
Área
ci-cd, cli, cloud

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
916
Forks
53
Merge medio
18 h 42 min
PR fusionados (30 d)
199

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de cloudflare/cf

Todos los issues de cloudflare/cf

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.