Cloudflare-Workers-Version-Overrides is ignored on fetch Service Binding when targeting a 0% version in the current deployment

[yoshikage1819-create]

Cloudflare-Workers-Version-Overrides is ignored on fetch Service Binding when targeting a 0% version in the current deployment

Summary

A production-deployed caller Worker made a fetch()-based Service Binding subrequest to a downstream Worker whose current deployment contained two versions: version A at 100% traffic and version B at 0% traffic. Setting Cloudflare-Workers-Version-Overrides to version B did not change the downstream behavior. Both the no-override and override requests executed version A behavior.

Classification: PRODUCTION_SERVICE_BINDING_OVERRIDE_NOT_APPLIED.

Documented expectation

The current Cloudflare Workers version overrides documentation states that an override can target a version in the current deployment, including a version serving 0% of traffic. It also states that Cloudflare-Workers-Version-Overrides can be set on a fetch()-based Service Binding subrequest, in which case the downstream Worker should execute the specified version.

Environment

• Wrangler 4.129.0
• Module Workers
• Compatibility date: 2026-09-04
• Caller and downstream Worker in the same Cloudflare account
• Downstream active deployment contained exactly two versions:
  • version A: 100% traffic
  • version B: 0% traffic
• The target version B was part of the current deployment, not merely an uploaded preview version.
• Service Binding used fetch(), not RPC.
• No custom domain was required.

Minimal reproduction shape

Use two Workers:

downstream-worker

• Version A exposes exactly three observable MCP tools.
• Version B exposes exactly four observable MCP tools.
• Its active deployment is A = 100% and B = 0%.

caller-worker

• Has exactly one Service Binding: DOWNSTREAM to downstream-worker.
• Builds the same outgoing request in both tests.
• Test A sends no version override.
• Test B adds only the version-override header.

const headers = new Headers(baseHeaders);

if (useOverride) {
  headers.set(
    "Cloudflare-Workers-Version-Overrides",
    'downstream-worker="<version-B-id>"',
  );
}

return env.DOWNSTREAM.fetch(
  new Request("https://downstream.example/mcp", {
    method: request.method,
    headers,
    body,
  }),
);

The reproduction also set an explicit canonical Host header derived from the downstream request URL because the downstream MCP handler validates Host. That resolved an earlier authenticated 403 and is separate from the version-override result: both Test A and Test B used the same canonical Host header.

Observed production result

The caller was deployed as a normal Worker with a temporary workers.dev endpoint. It was not run with wrangler dev --remote, edge preview, or a temporary-deployment command.

Before authentication, the caller-to-downstream path returned the expected 401 with the downstream OAuth challenge. Canonical OAuth authorization, callback, and allowlist validation then passed.

Test A — no override

• Authenticated downstream MCP initialization: PASS
• Observed version A behavior
• Exactly three tools: render_bridge_canary, canary_ping, model_pipeline_probe

Test B — override targeting version B

• Authenticated downstream MCP initialization: PASS
• Still observed version A behavior
• Exactly the same three tools: render_bridge_canary, canary_ping, model_pipeline_probe
• No error indicated that the override header was malformed.
• The candidate version remained at 0% in the downstream current deployment.

The same OVERRIDE_NOT_APPLIED behavior was observed earlier from wrangler dev --remote / edge preview. The important result here is that the behavior also reproduces from a normally deployed production-runtime caller.

Safety and control evidence

• Version B was confirmed to be in the downstream current deployment at 0%.
• Baseline and override requests used the same Service Binding, canonical request URL, canonical Host header, authenticated request path, and MCP verifier.
• Authenticated initialization succeeded in both tests.
• The only semantic request difference was Cloudflare-Workers-Version-Overrides.
• Downstream application state was unchanged during the reproduction.
• The disposable production caller was deleted immediately after testing.

Expected result

Test B should execute version B and expose four-tool behavior.

Actual result

Test B executed the same 100%-traffic version A behavior as Test A and exposed the same three tools.

Related context

This may relate to cloudflare/workers-sdk#9342. This reproduction is narrower: it concerns the currently documented ability to override a version that is already in the active deployment at 0%, not arbitrary uploaded preview versions.

Questions for Cloudflare

1. Is fetch-based Service Binding version override currently supported in production for a target version at 0%?
2. If yes, is this a platform bug?
3. Is there an undocumented restriction involving workers.dev, OAuth-protected downstream Workers, or manually constructed Request objects?
4. Is there a supported way to observe whether the routing layer accepted or rejected a version override?

[workers-devprod]

Automated triage

Issue assessment

• Actionability: ✅ Actionable.
• Type: Bug (high confidence).
• Reproduction: Skipped automatically.
• Labels:
  • question (medium)
  • awaiting-response:cloudflare (medium)
  • needs-reproduction (medium)
  • upstream:workerd (low)

Actionability and missing information

Bug report: documented Cloudflare-Workers-Version-Overrides header on a fetch-based Service Binding subrequest allegedly ignored when targeting a 0% version in the downstream deployment; override and baseline both ran version A. Repro shape and controls supplied, but no account IDs or wire traces.

Reproduction reason: Reproduction requires a production Cloudflare account with a downstream Worker whose active deployment contains a 0% version, an OAuth-protected MCP endpoint, and a bound caller Worker, which cannot be exercised automatically from this repository.

Missing information:

• environment
• error output
• minimal reproduction
• affected scope

---

This summary was generated by an LLM and may contain errors. Please verify its findings.