Next.js 16 does not forward proxy errors to `onRequestError`

[chargome]

Link to the code that reproduces this issue

https://github.com/chargome/repro.next-16-proxy-errors

To Reproduce

Reproduction steps are outlined in the repro readme.

Current vs. Expected behavior

• Throwing errors from within a proxy.ts file do not get reported via onRequestError ❌
• Throwing errors from within a middleware.ts file do get reported via onRequestError ✅

I would expect the error reporting to behave identically between these two files.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:49 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 20.14.0
  npm: 10.7.0
  Yarn: 1.22.22
  pnpm: 9.4.0
Relevant Packages:
  next: 16.0.0 // Latest available version is detected (16.0.0).
  eslint-config-next: N/A
  react: 19.2.0
  react-dom: 19.2.0
  typescript: 5.9.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Middleware

Which stage(s) are affected? (Select all that apply)

next start (local), next dev (local), Vercel (Deployed)

Additional context

No response

[git-wizard]

I believe that in middleware, errors thrown inside were surfaced through the request lifecycle, meaning onRequestError would report them.

However, proxy is intended to act as a network boundary and routing layer and is executed outside the request instrumentation pipeline used by onRequestError.

Correct me if im wrong, but I believe this is totally expected behavior and you shouldn't be doing anything outside "rewriting, redirecting, modifying the request or response headers, or responding directly" as stated in the documentation for proxy.

[chargome]

According to the migration docs

What to do: Rename middleware.ts → proxy.ts and rename the exported function to proxy. Logic stays the same.

I would not expect this core functionality to change.

Correct me if im wrong, but I believe this is totally expected behavior and you shouldn't be doing anything outside "rewriting, redirecting, modifying the request or response headers, or responding directly" as stated in the documentation for proxy.

This is not about deliberately throwing errors in proxies but rather providing a way for monitoring services to capture these exceptions in production.