[wrangler] Display build errors for auxiliary workers in multi-worker mode

[petebacondarwin]

Fixes #13129.

When running wrangler dev with multiple -c config flags (multi-worker mode), build errors from auxiliary/secondary workers were only logged at debug level. This caused Wrangler to silently hang because the MultiworkerRuntimeController never received a bundleComplete event for the failing worker, so #canStartMiniflare() never returned true.

The fix centralizes build error logging in DevEnv.handleErrorEvent():

1. DevEnv.ts — Added a new branch that treats BundlerController errors as recoverable (like ParseError from ConfigController). For esbuild BuildFailure errors, it uses logBuildFailure() to produce the same nicely-formatted output (with source locations, notes, and suggestions) that the primary worker already gets via handleError(). For non-esbuild bundler errors, it falls back to logging the error message.

2. BundlerController.ts — Removed the 5 logger.error() calls that preceded each emitErrorEvent() call. Previously these caused double-logging because both BundlerController and the DevEnv error handler would log the same error. Error display is now solely handled by DevEnv, which is the central event dispatcher.

This applies to all workers (primary and auxiliary), ensuring build errors are always visible, well-formatted, and logged exactly once.

Important review considerations

• The logger.error() calls were removed from BundlerController at 5 sites (custom build failure, tmp dir creation, startCustomBuild catch, startBundle catch, ensureWatchingAssets catch). The #startBundle runBuild error callback never had a logger.error() call, so it was already consistent with this approach.
• Verify no external code relies on listening for re-emitted error events on the DevEnv EventEmitter — BundlerController errors are now handled directly rather than falling through to this.emit("error", event).
• The non-esbuild fallback logs only event.cause.message. The event.reason (e.g. "Custom build failed") is still logged at debug level by the constructor listener. If richer context is desired for non-esbuild errors, the fallback could be adjusted.
• The server will still not start if an auxiliary worker fails to build (since #canStartMiniflare() requires all workers), but the error is now visible so the user knows what to fix.

Human review checklist

• Confirm that all code paths calling emitErrorEvent in BundlerController reach DevEnv.handleErrorEvent() — removal of the logger.error() calls relies on this
• Check whether any consumers depend on BundlerController errors being re-emitted via this.emit("error", event) on the DevEnv EventEmitter (they now get handled inline instead)
• Verify the isBuildFailure / isBuildFailureFromCause type guards correctly detect all esbuild error shapes that BundlerController can produce

---

• Tests
  • Tests included/updated
  • Automated tests not possible - manual testing has been completed as follows:
  • Additional testing not necessary because:
• Public documentation
  • Cloudflare docs PR(s):
  • Documentation not necessary because: this is a bug fix for error visibility, no public-facing API or config changes

Link to Devin session: https://app.devin.ai/sessions/ddf3cd9d12e941feb73d87d26da8d1ec
Requested by: @petebacondarwin

---

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR that start with 'DevinAI' or '@devin'.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[changeset-bot]

🦋 Changeset detected

Latest commit: d760e83

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

✅ All changesets look good

[ask-bonk]

The DevEnv.test.ts is a new file for DevEnv-specific tests. There wasn't one before. This is appropriate — every other controller in this directory already has its own test file.

After thorough review, this is a clean, well-scoped bug fix:

1. The 4-line production code change correctly intercepts BundlerController errors and logs them at error level, preventing them from being swallowed.
2. The tests adequately verify the behavior.
3. The changeset is well-written.
4. No backward compatibility concerns — the only code that previously consumed the re-emitted error events was the constructor's own debug-level listener (line 66-69), which still fires for other error sources.

LGTM

github run

[workers-devprod]

Codeowners approval required for this PR:

• ✅ @cloudflare/wrangler

Show detailed file reviewers

[pkg-pr-new]

create-cloudflare

npm i https://pkg.pr.new/create-cloudflare@13136

@cloudflare/kv-asset-handler

npm i https://pkg.pr.new/@cloudflare/kv-asset-handler@13136

miniflare

npm i https://pkg.pr.new/miniflare@13136

@cloudflare/pages-shared

npm i https://pkg.pr.new/@cloudflare/pages-shared@13136

@cloudflare/unenv-preset

npm i https://pkg.pr.new/@cloudflare/unenv-preset@13136

@cloudflare/vite-plugin

npm i https://pkg.pr.new/@cloudflare/vite-plugin@13136

@cloudflare/vitest-pool-workers

npm i https://pkg.pr.new/@cloudflare/vitest-pool-workers@13136

@cloudflare/workers-editor-shared

npm i https://pkg.pr.new/@cloudflare/workers-editor-shared@13136

wrangler

npm i https://pkg.pr.new/wrangler@13136

commit: 1786439

[dario-piotrowicz]

LGTM with a small comment