Regression of #4562: `Error inside ProxyWorker` kills `wrangler dev`, and the printed error is empty

[FallouKebe]

This is the same symptom as #4562 ("Network connection lost." surfaced as "Error inside ProxyWorker"), which was closed in the 3.x line. We see it on 4.125.0 through a different code path, so I am filing it as a regression rather than a new report.

What versions & operating system are you using?

The failure happens only in CI, so the workstation envinfo would describe a machine where the bug does not occur. The environment that matters:

• GitHub Actions ubuntu-latest, private repository — 2 cores, 8 GB
• Node 24
• wrangler 4.125.0
• @cloudflare/workerd-linux-64 1.20260820.1
• miniflare 5.20260820.0-alpha
• Next.js 16.2.12 via @opennextjs/cloudflare
• Two wrangler dev servers running concurrently on the same runner

Please provide a link to a minimal reproduction

I do not have one, and I would rather say so than link something that does not reproduce.

The trigger is environmental — a connection dropped mid-response, which we only ever see under contention on a small runner. But the defect itself is in wrangler's own source and does not depend on our code: the path below produces an empty Error unconditionally, for any project. The analysis is source-level, and I have included the exact code so it can be checked without running anything.

Happy to provide more logs or to test a patch.

Describe the Bug

wrangler dev exits mid-session with:

✘ [ERROR]
🪵  Logs were written to ~/.config/.wrangler/logs/wrangler-<date>.log
ERROR Wrangler dev command failed:

The [ERROR] line carries no message at all. The real one is in the log file, at debug level:

Error in ProxyController: Error inside ProxyWorker
    at castErrorCause      (wrangler-dist/cli.js)
    at ProxyController.emitErrorEvent
    at ProxyController.onProxyWorkerMessage
  cause: {
    name: 'Error',
    message: 'Network connection lost.',
    stack: 'Error: Network connection lost.'
  }

So the information exists. It is simply not on the line a user reads.

Why the printed error is empty. ProxyWorker.js posts the failure to the controller as a plain object, because an Error cannot cross the worker boundary:

void fetch(userWorkerUrl, new Request(request, { headers }))
  .then(...)
  .catch((error) => {
    if (isSameUserWorkerOrigin(userWorkerUrl, this.proxyData?.userWorkerUrl)) {
      void sendMessageToProxyController(this.env, {
        type: "error",
        error: { name: error.name, message: error.message,
                 stack: error.stack, cause: error.cause },
      });

cli.js then reconstructs it:

function castErrorCause(cause) {
  if (cause instanceof Error) return cause;
  const error = new Error();      // no message
  error.cause = cause;
  return error;
}

The posted value is never an Error, so this path always yields an Error with an empty message. emitErrorEvent dispatches it, and the dev server stops.

wrangler already treats two neighbouring conditions as non-fatal. DevEnv.handleErrorEvent has an exemption branch, and it is two reasons wide:

handleErrorEvent(event) {
  if (event.cause instanceof MiniflareCoreError && event.cause.isUserError())
    this.emit("error", new UserError(...));
  else if (event.source === "ProxyController" &&
           (event.reason.startsWith("Failed to send message to") ||
            event.reason.startsWith("Could not connect to InspectorProxyWorker"))) {
    logger.debug(`Error in ${event.source}: ${event.reason}`, event.cause);
    logger.debug("=> Error contextual data:", event.data);
  } else this.emit("error", event);   // fatal
}

The design already recognises that a ProxyController error can be transient and should only be logged. Error inside ProxyWorker — a rejected proxy fetch — is the same kind of condition, and falls through to the fatal else. There is no configuration escape: the fatality is hardcoded.

Why it matters beyond a missing message. The rejection is transient: one connection cut mid-response is enough. A single one takes the whole dev server down, and every request after it fails. In our end to end suite that is 169 tests failing for one dropped connection, with nothing on the console to say why.

Two suggestions, in order of value:

1. castErrorCause could rebuild a real Error from the posted shape, which already carries name, message and stack. The information exists and is discarded at the exact moment a user needs it.
2. Error inside ProxyWorker could join the exemption branch above. It is a transient network condition, not a configuration fault, and the code already makes that distinction for its two neighbours.

Please provide any relevant error logs

Observed 8 times over 31 CI runs. The crash always lands on the same test, and the number of failures after it is identical every time. Never reproduced on a developer machine, where the same suite passes.

One data point that may help you place it: after splitting our suite so each job runs one server instead of two, the crash has not recurred — 2 runs, which we do not consider proof. That is consistent with contention producing the dropped connection. The dropped connection being fatal is the part being reported here.

[workers-devprod]

Automated triage

• Reproduction: ⚠️ Blocked.
• Actionability: ✅ Actionable.
• Type: Bug (high confidence).
• Labels:
  • package:wrangler (high)
  • start-dev-worker (high)
  • error-messaging (medium)

Reproduction details

Automated reproduction failed before producing a result.

Actionability and missing information

Actionable bug report: a transient dropped connection in wrangler dev ProxyWorker becomes a fatal, empty-message error; reporter provides source-level analysis, exact code paths, and logs, but no minimal reproduction.

Missing information:

• minimal reproduction
• reproduction steps

[FallouKebe]

Following the triage note asking for reproduction steps and a minimal reproduction: here are the steps, and — more usefully I hope — three mechanisms I tried and ruled out. I could not build a minimal repro, and I would rather report the failed attempts than link something that does not reproduce.

Steps that produce it for us

1. Two wrangler dev servers started concurrently by Playwright's webServer, on a 2-core GitHub Actions runner (private repo tier).
2. A browser suite drives one of them for several minutes.
3. At some point one proxy fetch toward the user worker rejects with Network connection lost.
4. The dev server exits, printing an empty ✘ [ERROR]. Everything after fails.

It happened 8 times over 31 runs, always landing on the same test, with an identical number of failures after it. Splitting the suite so each job runs one server has so far avoided it (a small number of runs, not proof).

Three mechanisms I ruled out, with what each produced instead

I built a minimal worker returning a slow TransformStream and drove it with wrangler dev 4.125.0:

attempt	result
Client aborts mid-response (AbortController after the first chunk, 5×)	dev server unaffected, nothing logged
Worker aborts its own stream (writer.abort(...))	Uncaught Error reported for the worker, dev server survives
File touched to trigger a reload while a response is streaming	reload happens, dev server survives

So none of the obvious client-side or worker-side disconnections reach the ProxyController error path. Network connection lost. appears to require losing the user worker connection itself, which is what I suspect contention on a small runner produces — and what I could not script.

Why I think the report still stands without a repro

The trigger is environmental, but the two defects are not:

1. castErrorCause builds new Error() with no message whenever the posted cause is not an Error — and ProxyWorker.js always posts a plain object. That is unconditional for this path, independent of what triggered it.
2. The rejection is fatal, while two neighbouring ProxyController reasons are already exempted in DevEnv.handleErrorEvent.

Both are visible in the source shipped in wrangler-dist/, and neither depends on our code.

Happy to run any instrumented build you would like, or to test a patch against the workload that reproduces it.

[acoBOYZ]

Same empty ✘ [ERROR] on wrangler 4.125.0 (macOS, Bun, multiple concurrent wrangler dev via Turborepo).

Our worker keeps returning successfully, but under ~dozens of concurrent long-poll requests the debug log shows:

Error in ProxyController: Error inside ProxyWorker cause: { message: 'Network connection lost.' }

Then wrangler dev exits and takes the whole turbo dev graph down.

Pinning worker packages to wrangler 4.113.0 looks like stopped it for us.

[NuroDev]

@workers-devprod reproduce

[sarbogergely]

Another data point, and I think it narrows things usefully: we hit this with a single wrangler dev, on a workstation, not in CI.

Every report on this thread so far involves concurrent dev servers — two on a 2-core runner (@FallouKebe), several via Turborepo (@acoBOYZ). Ours has neither. One wrangler dev, one Playwright suite driving it, Windows 11, plenty of cores and RAM. Same empty ✘ [ERROR], same cause:

Error in ProxyController: Error inside ProxyWorker
 Error
    at castErrorCause (wrangler/wrangler-dist/cli.js)
    at ProxyController2.emitErrorEvent
    at ProxyController2.onProxyWorkerMessage
    at process.processTicksAndRejections (node:internal/process/task_queues)
    at async #handleLoopbackCustomFetchService (miniflare/dist/src/index.js)
    at async #handleLoopback (miniflare/dist/src/index.js)
  cause: {
    name: 'Error',
    message: 'Network connection lost.',
    stack: 'Error: Network connection lost.'
  }

So whatever the trigger is, it does not require two dev servers competing. That seemed worth saying, because "contention between servers" is the obvious hypothesis from the reports so far, and it does not hold for us.

Versions — the newest release is still affected

@FallouKebe saw it on workerd 1.20260820.1; @acoBOYZ on wrangler 4.125.0. We see it on both of these:

wrangler	miniflare	workerd
4.118.0	5.20260730.0-alpha	1.20260730.1
4.126.0	5.20260825.0-alpha	1.20260825.1

We upgraded 4.118.0 → 4.126.0 specifically hoping it would fix this. It did not.

(@acoBOYZ — for what it's worth, pinning to 4.113.0 may still be a valid workaround, but we can confirm 4.118.0 is not far enough back.)

A frequency number, since nobody has given one

Five consecutive full runs of the same browser suite (~96 tests, ~2.5 min each, one dev server, nothing else running):

run	result
1	✅ 96 passed
2	✅ 96 passed
3	❌ dev server exited — 27 failed / 69 passed, 23× ECONNREFUSED after the exit
4	✅ 96 passed
5	✅ 96 passed

So roughly 1 in 5 for this workload. Earlier, on the 4.118.0 pairing, we saw 2 failures in 3 runs — but those ran while the machine was under other heavy load, so I would not compare the two rates. The honest statement is just: it still happens on the newest workerd, and it does not need a loaded machine.

Confirming the empty-error analysis

Your source-level explanation of why ✘ [ERROR] prints nothing matches exactly what we see: the message is never lost, it just isn't on the line a human reads. We ended up writing a small script that greps the cause out of the debug log and prints it into our CI job summary, because otherwise triage starts with "download the artifact and read 20 MB of log". Happy to share it if it is of any use, though it is really just a workaround for the printing bug you already diagnosed.

⚠️ One caution for anyone else doing that: the wrangler debug log embeds your bundled Worker source. Secret values are redacted (("(hidden)")), but the code is not — we found minified fragments of our own worker in it. Worth knowing before attaching one to a public issue. That is also why I am quoting only the stack frames and the cause block above, not the log.

Not #15203

We do have assets configured, so we checked whether we were actually hitting #15203 (POST-with-body to an asset path). We are not: across the five runs above the POST profile was byte-identical (20 POSTs, 2 of them 405) and only run 3 died. A deterministic trigger does not explain that, and our 405s come from the user Worker's router rather than the assets layer. Mentioning it so the two reports stay separable.

We do not have a minimal reproduction either, and I would rather say so than link something that does not reproduce. But we can test a patch or a debug build on Windows and on Linux CI, and we can run the suite as many times as needed to get a before/after rate — just say what would help.

[maniflopi]

Another data point, and it narrows the trigger further than the report assumes: we reproduce this on a developer machine, with a single wrangler dev, and without contention.

Setup: macOS on Apple Silicon (8 cores, 24 GB), wrangler 4.120.1, one wrangler dev -c dist/server/wrangler.json --local, Playwright driving it. Astro 7 with the Cloudflare adapter, so static assets are configured. No second server, nothing else running.

Rate, measured over two batches of ten identical runs on the same commit:

environment	crashes
laptop, 8 cores, 1 server, idle machine	1 of 10
GitHub Actions ubuntu-latest, private repo (2 cores), 1 server	2 of 2

Same signature both times — the empty ✘ [ERROR], and in the debug log:

Error in ProxyController: Error inside ProxyWorker
    at castErrorCause
  cause: { name: 'Error', message: 'Network connection lost.' }

The laptop case is the one I think is useful to you. The report says it was never reproduced on a developer machine, and that the trigger is contention on a small runner. Contention clearly multiplies it — 2 of 2 versus 1 of 10 — but it does not appear to be necessary. On the laptop run the server had been up for 25 seconds and was serving ordinary static assets when it died; the requests immediately before it were .js, .woff2 and .webp, all 200.

A detail that may or may not matter: the suite that triggers it issues 849 POST requests with a JSON body per run to a Worker route (an analytics beacon), alongside normal navigation. That is a lot of request churn with bodies, which is the shape #15203 points at — though there the POSTs target a path where an asset exists, and here they do not.

On the two suggestions in the report: from the outside, the second one is what would have saved us. We spent a day treating this as flakiness in our own suite — a red run of 119 failures reads exactly like a broken commit, and 110 of those failures were ERR_CONNECTION_REFUSED only visible once we correlated the wrangler log by timestamp. Rebuilding a real Error in castErrorCause would have pointed at it on the first run instead of the twelfth.

Happy to test a patch on either environment; the 2-core CI one reproduces it every time, which makes it a cheap oracle.

[mvoltolina]

Another data point, from a different stack and a different trigger — which I think widens this usefully in three ways: it persists on 4.127.0, it happens with a single wrangler dev (not two), and it is not framework-specific.

Environment

• GitHub Actions ubuntu-latest, private repo
• wrangler 4.127.0 (also seen on 4.126.0), @cloudflare/workerd-linux-64 — Linux build
• Astro 7 via @astrojs/cloudflare, not Next.js/OpenNext
• One wrangler dev process on the runner, plus a postgres:16 service container
• Driven by Playwright against wrangler dev --port 4321

Symptom — identical to this issue

wrangler dev serves normally, then exits. Our stdout capture ends with the bare empty banner:

✘ [ERROR]

If you think this is a bug then please create an issue at ...

WRANGLER_LOG=debug gives the part that is missing from stdout:

--- error
✘ [ERROR] 

--- debug
Error
    at castErrorCause (.../wrangler/wrangler-dist/cli.js:180603:20)
    at ProxyController2.emitErrorEvent (.../wrangler/wrangler-dist/cli.js:326752:20)
    at ProxyController2.onProxyWorkerMessage (.../wrangler/wrangler-dist/cli.js:326629:18)
    at PROXY_CONTROLLER (.../wrangler/wrangler-dist/cli.js:326356:24)
    at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
    at async #handleLoopbackCustomFetchService (.../miniflare/dist/src/index.js:112343:22)
    at async #handleLoopback (.../miniflare/dist/src/index.js:112726:20)

--- info
uncaught exception; source = Uncaught (in promise); stack = Error: Network connection lost.

--- info
uncaught exception; exception = workerd/jsg/_virtual_includes/iterator/workerd/jsg/value.h:1477: disconnected: jsg.Error: Network connection lost.

Reproducible timing signature

It is not random. Across four occurrences it dies in the opening burst, when Playwright's workers all navigate at once:

run	suite starts	first failure	elapsed	specs passed first
A	03:50:11	03:50:21	10s	31
B	21:40:01	21:40:10	9s	28

Everything after that is ERR_CONNECTION_REFUSED.

Two plausible mitigations, both refuted with evidence

Recording these because they are the first two things anyone tries:

1. Halving concurrency did nothing. Playwright workers: 4 → 2. Same death, same window.
2. Upgrading did nothing. 4.126.0 → 4.127.0 (which wrangler's own error output suggests on every occurrence). Same death.

Not memory, and not the user Worker

• No OOM signature in any run: no heap out of memory, no exit 137, no SIGKILL, no ENOMEM.
• Locally workerd holds ~66 MB → ~118 MB across ~1000 concurrent requests over five routes and does not die; the same suite passes at 4 workers on macOS. Only the Linux CI build dies.
• No frame in the stack is ours — every one is wrangler-dist/cli.js or miniflare/dist.
• We do have [assets] configured, but unlike wrangler dev exits with "Error inside ProxyWorker / Network connection lost" on POST requests with a body when assets is configured #15203 we see no 405s at all, and the POSTs in flight reach the Worker (302/403). So the assets-layer path does not appear to be required to hit this.

Production Workers with the same code show nothing, consistent with the ProxyController being a wrangler dev-only component.

What we did about it

Since the four stack frames name wrangler's own proxy plumbing and cannot appear if the crash came from our Worker, we gate a single CI retry on requiring all four of Network connection lost, castErrorCause, ProxyController and handleLoopback in the debug log. A second failure is reported as real regardless. Sharing the shape in case it is useful to anyone else parking this until it is fixed — it deliberately refuses to fire on an application crash that shares the surface symptom.

Happy to run instrumented builds or capture anything more specific if that would help.

[DamienGR]

Another data point, with a measurement I have not seen on this thread: the fault tracks the runner instance, not the moment. Two identical jobs from the same matrix, same commit, same image, minutes apart — one never sees it, the other kills every dev session it starts, up to eight in a row.

Setup

Runner	GitHub Actions ubuntu-latest, private repo
Node	22
wrangler	4.126.0 (miniflare 5.20260825.0-alpha, workerd 1.20260825.1) and 4.127.1 (…0828.0-alpha / …0828.1)
Dev servers	one, wrangler dev --config dist/server/wrangler.json
Driver	a shell script issuing one curl at a time, sequentially

No browser, no Playwright, no second server, no concurrency of any kind — one request in flight, ever. X_LOCAL_OBSERVABILITY=false and X_LOCAL_EXPLORER=false are both set, so the extra dev-proxy services are off. Same empty ✘ [ERROR], and the same four frames everyone else has posted (castErrorCause → emitErrorEvent → onProxyWorkerMessage → #handleLoopbackCustomFetchService).

That narrows @sarbogergely's point further: concurrent dev servers are not required, and neither is concurrent load.

The measurement

The suite takes ~50s, so I ran it as a 10-job parallel matrix and counted outcomes. Then I wrapped it in a re-run that starts a completely fresh wrangler dev and a fresh state directory on the same runner, and counted again.

configuration	runs	dev-session deaths
bare suite	20	5
re-run, up to 3 fresh sessions	30	3 runs still failing (10%)
re-run, up to 8 fresh sessions	20	1 run still failing (5%)

The shape matters more than the rates. Of every run that saw a death, recovery came on session 2, 2, 2, 3, 3 or 4 — never later. The runs that did not recover by then did not recover at all: the one failure in the 8-session sweep died all eight times, each on a brand-new process, brand-new state directory, at the same request. Meanwhile nine sibling jobs in that same matrix passed on their first session.

So a runner appears to be either healthy or persistently fatal for the life of the job, which is why re-running in place plateaus at 5% no matter how high the ceiling goes. Moving the work to a different runner is a fresh draw and gets it under 1%. If that holds generally, "transient under contention" may be the wrong model — it looks more like a property of the individual machine (kernel, CPU model, cgroup or network-stack variation between runner images).

Also ruled out

• 4.127.1 is still affected (thread has 4.127.0).
• An unread request body. Our death always lands on the request following a POST whose handler returns 401 without ever reading request.body — the only such request in the suite, and the position is identical across every occurrence. Releasing it with await request.body?.cancel() before responding changed nothing: 3 deaths in 10 against 2 in 10 for the control.

Happy to run instrumented builds, or to dump anything specific from an affected runner — the matrix makes one cheap to catch.