Wrangler deploy repeatedly fails with write EPIPE on Workers Versions API after asset upload

[johnwheeler]

What versions & operating system are you using?

System:
  OS: macOS 26.2
  CPU: (24) arm64 Apple M2 Ultra
  Memory: 49.52 GB / 128.00 GB
  Shell: 5.9 - /bin/zsh
Binaries:
  Node: 26.5.0
  npm: 11.17.0
npmPackages:
  @opennextjs/cloudflare: 1.20.1
  @prisma/adapter-pg: 7.8.0
  @prisma/client: 7.8.0
  next: 16.2.10
  prisma: 7.8.0
  wrangler: 4.123.0

The same failure also occurred with Wrangler 4.110.0 before upgrading to 4.123.0.

Please provide a link to a minimal reproduction

There is no public reproduction repository because this is a private production project. The failure reproduces consistently by running the project's OpenNext production deploy (CLOUDFLARE_ENV=production opennextjs-cloudflare deploy). A closely related prior report is #14922.

Describe the Bug

Wrangler completes configuration processing, reads/uploads static assets, fetches the existing Worker settings successfully, and then consistently fails while creating the Worker version:

POST /accounts/<account-id>/workers/scripts/<worker-name>/versions
TypeError: fetch failed
  [cause]: Error: write EPIPE
    errno: -32
    code: 'EPIPE'
    syscall: 'write'

Wrangler retries the Versions API request three times. Each attempt fails after approximately 15 seconds without receiving an HTTP response.

Other Cloudflare API requests in the same deploy succeed. In the latest attempt:

• The asset upload returned HTTP 201.
• GET /workers/scripts/<worker-name>/settings returned HTTP 200.
• Only POST /workers/scripts/<worker-name>/versions failed.

The generated Worker is 15,749.04 KiB uncompressed / 3,880.29 KiB gzip. This account is on the Workers Paid plan. An almost identical bundle (15,748.80 KiB / 3,880.38 KiB gzip) deployed successfully from the same machine earlier on August 16, 2026, so this does not appear to be a bundle-size rejection.

The machine has normal connectivity and is not using a VPN, firewall, or explicit proxy. The behavior is consistent across repeated attempts and persisted after upgrading Wrangler.

This resembles #14922 and the Cloudflare incident documented at https://www.cloudflarestatus.com/incidents/z325n2dc14tk: other API calls and asset upload succeed, but the Versions API fails. That incident produced an HTML 403 WAF response, whereas this failure closes the connection with EPIPE before Wrangler receives any response. The project also uses Prisma with @prisma/adapter-pg, as did one of the reports in #14922.

Expected behavior: Wrangler should create and deploy the new Worker version, or return a structured API error explaining why the version was rejected.

Please provide any relevant error logs

Sanitized excerpt from the latest Wrangler debug log:

2026-08-16T21:01:41.553Z
POST https://api.cloudflare.com/client/v4/accounts/<account-id>/workers/assets/upload?base64=true

2026-08-16T21:01:42.286Z
HTTP 201 Created

2026-08-16T21:01:42.557Z
GET https://api.cloudflare.com/client/v4/accounts/<account-id>/workers/scripts/<worker-name>/settings

2026-08-16T21:01:42.832Z
HTTP 200 OK

2026-08-16T21:01:42.839Z
POST https://api.cloudflare.com/client/v4/accounts/<account-id>/workers/scripts/<worker-name>/versions

2026-08-16T21:01:58.008Z
TypeError: fetch failed
  [cause]: Error: write EPIPE

2026-08-16T21:01:58.009Z
Retry: POST .../versions

2026-08-16T21:02:13.293Z
TypeError: fetch failed
  [cause]: Error: write EPIPE

2026-08-16T21:02:14.295Z
Retry: POST .../versions

2026-08-16T21:02:29.683Z
TypeError: fetch failed
  [cause]: Error: write EPIPE

Because the connection closes before an HTTP response is received, the log contains no status code or Cloudflare Ray ID for the failed requests.

[workers-devprod]

Note

This is an automated, advisory triage report generated by workers-devprod. It is not an official maintainer response — a maintainer will follow up.

🤖 Automated triage report

Issue Triage: #15230

Summary

Wrangler deploy consistently fails at POST /accounts/<id>/workers/scripts/<name>/versions with TypeError: fetch failed caused by write EPIPE, while every other API request in the same deploy (asset upload, settings fetch) succeeds.

Classification

• Type: Bug
• Component: packages/wrangler
• Severity: High
• Has Reproduction: No (private production project; no public repo)
• Quality: Partial

Findings

• Created: 2026-08-16T22:27:05Z
• Author: johnwheeler
• Version: wrangler 4.123.0 (also reproduced on 4.110.0); Node 26.5.0; macOS 26.2 (arm64 M2 Ultra); @opennextjs/cloudflare 1.20.1; next 16.2.10; prisma 7.8.0; @prisma/adapter-pg 7.8.0
• Labels: awaiting-response:reporter, package:wrangler
• Comments: 2 (both automated triage reports from the workers-devprod bot; no human/reporter follow-up yet)

Analysis

• Component: The failing call is the versions-upload path (POST .../workers/scripts/<name>/versions), which is Wrangler's responsibility, so this maps to packages/wrangler.
• Error nature: write EPIPE (errno -32) means the peer closed the socket while Wrangler was still writing the request body. All 3 retries fail after ~15s with no HTTP response — a connection-level failure during upload, not an application-level 4xx/5xx API error.
• Selective failure correlated with payload size: Asset upload returned 201 and GET .../settings returned 200 in the same deploy; only the large versions POST (~15,749 KiB uncompressed / ~3,880 KiB gzip — by far the largest payload) fails. This points to size/duration correlation rather than auth or general connectivity.
• Not a hard size limit: An almost identical bundle (~15,748 KiB / ~3,880 KiB gzip) deployed successfully from the same machine earlier the same day, so the reporter argues it is not a deterministic size-limit rejection. A transient/flaky connection reset (client, proxy, or server) is the leading hypothesis; a server-side upload-timeout on the versions endpoint cannot be ruled out.
• Related report: The reporter explicitly cites Wrangler deploy blocked by Cloudflare WAF: 403 "Attention Required" on POST .../workers/scripts/.../versions #14922 as a closely related prior report (and notes both use Prisma with @prisma/adapter-pg) — worth cross-referencing for a shared root cause before investigating further. They also reference Cloudflare incident z325n2dc14tk, but note that incident returned an HTML 403 WAF response, whereas this closes the connection with EPIPE before any response.
• Reproducibility gap: No public reproduction is available (private production project) and the payload is large/environment-specific, making independent reproduction hard. This is the main blocker.
• Triage state: The issue already carries awaiting-response:reporter and a prior automated triage requesting diagnostics. There has been no reporter response yet, and the issue was created the same day, so it is not stale.

Recommendation

Status: NEEDS MORE INFO

Reasoning: The report is detailed and credible, but write EPIPE during a large upload with no HTTP response is ambiguous between a client-side/network connection reset and a server-side API/proxy issue, and there is no public reproduction. The specific network-level diagnostics needed to disambiguate this have already been requested but not yet supplied by the reporter.

Action: Keep the issue open awaiting the reporter's diagnostics. Cross-reference #14922 for a shared root cause. Once the requested logs and different-network/plain-wrangler deploy results arrive, determine whether the failure is client-side (wrangler/undici upload handling) or server-side (versions endpoint / proxy); if it proves to be a server-side connection reset with no wrangler-side fix, route it to the platform team. The awaiting-response:reporter label is already applied.

Suggested Labels: package:wrangler, awaiting-response:reporter

Suggested Comment

Thanks for the detailed report. write EPIPE here means the connection was closed while Wrangler was still uploading the version body, and since only the large POST .../versions request fails (assets and settings succeed), it looks correlated with the size/duration of that upload rather than auth or general connectivity. To help us narrow down whether this is a client-side or server-side issue, could you provide:

• The full output of WRANGLER_LOG=debug CLOUDFLARE_ENV=production opennextjs-cloudflare deploy (redacting account/worker identifiers), so we can see the exact request timing and headers around the failing call.
• Whether the failure still occurs when deploying from a different network (e.g. a non-corporate network, or without any VPN/proxy), and whether any HTTP proxy is configured in your environment.
• Whether a plain wrangler deploy (or wrangler versions upload) on the same bundle reproduces it, to rule out anything specific to the OpenNext flow.
• Confirmation of whether Wrangler deploy blocked by Cloudflare WAF: 403 "Attention Required" on POST .../workers/scripts/.../versions #14922 describes the same failure for you, so we can consolidate if it's the same root cause.

A network capture (or the exact time and account/worker of a failing attempt) would also help us check the versions endpoint from our side. Without a way to reproduce, this is the information we need to investigate further.

Structured summary (JSON)

{
  "issueNumber": 15230,
  "title": "Wrangler deploy repeatedly fails with write EPIPE on Workers Versions API after asset upload",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/15230",
  "recommendation": "NEEDS MORE INFO",
  "difficulty": "hard",
  "reasoning": "Detailed bug report of a write EPIPE during the large versions upload while all other API calls succeed, but there is no public reproduction and the failure is ambiguous between a client-side network reset and a server-side API/proxy issue.",
  "suggestedAction": "Keep open awaiting reporter diagnostics; cross-reference #14922, then use the WRANGLER_LOG=debug output plus different-network/proxy and plain wrangler deploy results to determine whether the fix is in wrangler or needs routing to the platform team.",
  "hasSuggestedComment": true,
  "suggestedLabels": ["package:wrangler", "awaiting-response:reporter"]
}

[workers-devprod]

• Reproduction: ⚠️ Blocked. Requires private production project and Cloudflare API credentials to deploy a large worker bundle to the live /versions endpoint. Sandbox lacks both, so the reported EPIPE failure cannot be reproduced against the actual API.