wrangler dev workerd exits on EPIPE while writing captured stdout

[adityak6798]

What happened

wrangler dev starts workerd successfully and serves requests for several minutes. When its stdout is captured by Playwright webServer, workerd can exit partway through the suite while writing request logs:

✘ [ERROR] kj::getCaughtExceptionAsKj() = kj/async-io-unix.c++:186:
          disconnected: ::write(fd, buffer.begin(), buffer.size()): Broken pipe

Wrangler then exits and every later request fails with ECONNREFUSED. In one run this produced 31 misleading browser assertion/time-out failures. The application log contained no request.exception entries; the runtime failed while writing its own log stream, not while serving product code.

We have observed six non-deterministic sightings across macOS and GitHub-hosted Linux runs. Re-running the same commit can fail different, disjoint specs. Representative hosted runs:

• https://github.com/adityak6798/ManageMyConference/actions/runs/31747167652 (the named kj/async-io-unix.c++:186 failure after about 14 minutes)
• https://github.com/adityak6798/ManageMyConference/actions/runs/31803323240 (degraded/socket-hang-up shape)
• https://github.com/adityak6798/ManageMyConference/actions/runs/31835694674 (two reruns of one commit failed different specs, then the API refused connections)

Configuration

• Wrangler 4.x (4.123.0 currently installed; the repository lockfile governs hosted runs)
• Playwright webServer launches npm run dev --workspace @greenroom/api
• request logs are JSON lines written to stdout/stderr
• one Playwright worker, local D1

Workaround

We now launch Wrangler under a small supervisor whose stdout/stderr are file descriptors for a checkout-local durable log rather than Playwright capture. Product request logging remains enabled. We also probe /health around every test so a runtime loss is reported once and later journeys are skipped.

Expected behavior

Closing or losing the stdout consumer should not terminate the Worker runtime. Wrangler/workerd should either keep serving with logging disabled for that sink, reopen/redirect the sink, or exit with one clear supervisor-level diagnostic that identifies stdout EPIPE rather than leaving consumers with unrelated request failures.

I can provide a fuller apps/api/.wrangler/wrangler.log excerpt if useful; it includes the kj message and stripped workerd frames but may contain application request metadata, so it is not pasted wholesale here.

[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: #15202

Summary

workerd (under wrangler dev) crashes with a Broken pipe / EPIPE error in kj/async-io-unix.c++:186 when its stdout/stderr is captured by Playwright's webServer and the consumer closes the pipe, causing Wrangler to exit and all subsequent requests to fail with ECONNREFUSED.

Classification

• Type: Bug
• Component: packages/wrangler (dev command runtime output handling; possibly packages/miniflare for the workerd process spawn)
• Severity: Medium
• Has Reproduction: Partial — no minimal clonable repro, but links to representative GitHub Actions runs and a precise error signature
• Quality: Complete

Findings

• Created: not available (metadata truncated in the pre-fetched context.json)
• Author: adityak6798 (Aditya Khandelwal)
• Version: Wrangler 4.123.0 (4.x)
• Labels: not available (metadata truncated)
• Comments: not available (metadata truncated)

Note: context.json stores the entire payload on a single very long line. The read/grep tooling (which caps line display at ~2000 chars, and this skill runs without bash) could only surface the issue body. Trailing metadata (labels, comments, state, dates) could not be extracted, though a probe confirmed "number":15202 exists later in the file. Triage below is based on the fully-visible issue body.

Analysis

• Root cause shape: The runtime does not fail while serving product code (no request.exception entries). It dies while writing its own JSON-line request logs to stdout/stderr. The kj/async-io-unix.c++:186 disconnected: ::write(...): Broken pipe signature indicates workerd received EPIPE because the downstream consumer (Playwright webServer capture) closed/stopped reading the pipe. This points at how the tooling pipes and drains the workerd child process's stdout/stderr, rather than at user code.
• Component: Best fit is packages/wrangler (the wrangler dev output/logging path). The underlying process spawn and stream wiring may live in packages/miniflare. Not a workerd runtime logic bug per se — it is an unhandled stream-disconnect / backpressure condition in the SDK's log piping.
• Reproducibility: Non-deterministic — "six non-deterministic sightings" across macOS and GitHub-hosted Linux; reruns of the same commit fail different, disjoint specs. Three representative hosted CI runs are linked. There is no minimal, self-contained repro the team can clone and run, which makes direct verification harder.
• Severity/impact: When it triggers, it takes down the whole dev server mid-suite and produced 31 misleading downstream test failures in one run — high blast radius. But it only manifests under a specific stdout-capture configuration (Playwright webServer capturing high-volume JSON request logs), and the reporter already has a working mitigation, so overall severity is Medium.
• Workaround exists: Reporter runs Wrangler under a supervisor that redirects stdout/stderr to a durable file rather than Playwright capture, plus /health probing — consistent with the theory that the failure is in the log-pipe consumer path.

Recommendation

Status: NEEDS VERIFICATION

Reasoning: This is a legitimate, well-described bug with a clear error signature and a plausible root cause (unhandled EPIPE when the workerd stdout consumer disconnects, likely combined with log backpressure). However, it is non-deterministic and has no minimal reproduction, so the team needs to verify and pin down the failing code path before committing to a fix.

Action: Keep open. A maintainer should confirm how the workerd child process's stdout/stderr is consumed in the wrangler dev path and whether an EPIPE/error handler is missing on that stream (and whether backpressure on high-volume request logging can wedge or crash the runtime). Ask the reporter for a minimal reproduction to speed this up.

Suggested Labels: none (repo labels could not be confirmed from the truncated metadata; omitting rather than guessing)

Suggested Comment

Thanks for the very detailed report — the kj/async-io-unix.c++:186 ... Broken pipe signature and your note that there are no request.exception entries strongly suggest the runtime is dying while writing its own log stream, not while serving your code, which most likely means we're mishandling an EPIPE/disconnect (or backpressure) on the workerd stdout/stderr pipe when the Playwright webServer capture stops reading.

To help us pin this down and verify a fix, could you share:

• A minimal reproduction (a small repo we can clone and run) that triggers the crash, even if it's flaky — ideally the smallest Playwright webServer + wrangler dev setup that reproduces it.
• The exact wrangler dev command / Playwright webServer config used, and whether you can reproduce it outside CI (locally on macOS).
• Roughly the log volume at the time of the crash (lines/sec), since high-throughput JSON logging into a paused consumer looks like the trigger.

Your supervisor-with-durable-log workaround is a useful data point and lines up with this being a stdout-consumer issue. We'll investigate the pipe handling on our side in the meantime.

Structured summary (JSON)

{
  "issueNumber": 15202,
  "title": "workerd crashes with Broken pipe (EPIPE) when wrangler dev stdout is captured by Playwright webServer, causing ECONNREFUSED for later requests",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/15202",
  "recommendation": "NEEDS VERIFICATION",
  "difficulty": "medium",
  "reasoning": "Well-described, plausibly real bug where workerd dies with EPIPE while writing its own log stream to a Playwright-captured stdout pipe, but it is non-deterministic and has no minimal reproduction. The team needs to verify the exact stdout-pipe handling path before committing to a fix.",
  "suggestedAction": "Keep open; a maintainer should audit how the workerd child process stdout/stderr is consumed in the wrangler dev path for a missing EPIPE/error handler or backpressure issue, and request a minimal reproduction from the reporter.",
  "hasSuggestedComment": true,
  "suggestedLabels": []
}

[workers-devprod]

• Reproduction: ✅ Successfully reproduced. Closing the stdout pipe of wrangler dev crashes the Node.js process with Error: write EPIPE, the dev server dies, and subsequent requests get ECONNREFUSED, matching the reported fatal behavior when the stdout consumer is lost.