PR #17995: feat(nextjs): Support node runtime on proxy files

• Repository: getsentry/sentry-javascript
• Author: chargome
• State: closed | merged: True
• Link: https://github.com/getsentry/sentry-javascript/pull/17995

Description (problem / solution / changelog)

Next 16 was released

With that proxy files run per default on nodejs.

This PR

• Updates the tests to run on next 16 (non-beta)
• Adds support for handling middleware transactions in the node part of the sdk

closes https://github.com/getsentry/sentry-javascript/issues/18006 closes https://github.com/getsentry/sentry-javascript/issues/18005 closes https://github.com/getsentry/sentry-javascript/issues/18008

Changed files

• dev-packages/e2e-tests/test-applications/nextjs-16/package.json (modified, +12/-1)
• dev-packages/e2e-tests/test-applications/nextjs-16/tests/middleware.test.ts (modified, +39/-26)
• packages/nextjs/src/common/nextSpanAttributes.ts (added, +3/-0)
• packages/nextjs/src/server/index.ts (modified, +30/-9)

PR #91523: Fix: Server Actions do not await onRequestError from instrumentation

• Repository: vercel/next.js
• Author: hamiltont
• State: open | merged: False
• Link: https://github.com/vercel/next.js/pull/91523

Description (problem / solution / changelog)

Bug Fix: Await onRequestError promise for server action errors

Disclaimer: This is my first time in the Next.js codebase. I used AI tooling (Claude) to help trace the error flow and generate the fix + test. I've done my best to verify the analysis, but I may have misread the code or missed context that's obvious to maintainers. Please take the specifics with a grain of salt — I'd rather flag that upfront than waste your time reviewing something built on a wrong assumption. Happy to adjust or close if the approach is off.

What?

Register the Promise returned by onRequestError (from instrumentation.ts) with after() when the error originates from a server action, so async error reporting completes before serverless runtimes tear down.

Why?

As far as I can tell, createReactServerErrorHandler in create-error-handler.tsx calls onReactServerRenderError(err, silenceLog) without awaiting the returned Promise. The Promise appears to be silently discarded, which would turn async error reporting into a race condition.

If this reading is correct, it would affect error tracking integrations that do async work inside onRequestError — Sentry, PostHog, Datadog, custom solutions, etc. The hook fires, but the async work (HTTP requests to ingest APIs) may not complete before the response lifecycle ends.

• Affected (I think): Server action errors (App Router)
• Not affected: Route handler errors (these appear to be properly awaited in app-route.ts)
• Severity: In serverless environments (Vercel Functions, AWS Lambda), the runtime may freeze or terminate after the response is sent. On long-running servers it would be a race condition but would usually complete in practice.

Error flow as I understand it: Server action throws → error wrapped in Promise.reject() → embedded in RSC payload → React's renderToReadableStream calls synchronous onError callback → onReactServerRenderError returns a Promise → Promise discarded (line 144).

Route handlers use a separate code path (app-route.ts:528) that properly awaits the same instrumentation chain.

How?

React's onError callback must be synchronous (returns a digest string), so we can't await inline. The fix uses Next.js's existing after() API to register the instrumentation promise with the platform's waitUntil mechanism. The after() call itself is synchronous — it just registers the promise — so the error handler still returns err.digest immediately.

const instrumentationPromise = onReactServerRenderError(err, silenceLog)
if (instrumentationPromise) {
  try {
    const { after } = require('../after/after')
    after(instrumentationPromise)
  } catch {
    // after() unavailable (e.g. build-time prerendering) — fall back to fire-and-forget
  }
}

The try/catch handles cases where AfterContext is unavailable (build-time prerendering, outside request scope).

Note: createHTMLErrorHandler in the same file has what looks like the same pattern — onHTMLRenderSSRError also returns a Promise that is discarded. I didn't touch it since I couldn't confirm with a concrete reproduction.

Test plan

• e2e test added at test/e2e/on-request-error/server-action-error-async/
• Test injects a mock waitUntil via @next/request-context (same pattern as test/e2e/app-dir/next-after-app)
• Test verifies waitUntil is called (proving after() registered the promise)
• Test verifies the error was actually reported (fetch to /write-log completed)
• Test verifies correct error metadata (route path, method, routerKind, routeType, renderSource)

Checklist

• Related issues linked
• Tests added
• No new errors requiring helpful links

Possibly related issues: #83404, #85261 Related: Sentry discussion #11709

Changed files

• packages/next/src/server/app-render/create-error-handler.tsx (modified, +20/-2)
• test/e2e/on-request-error/server-action-error-async/app/form-error/page.js (added, +17/-0)
• test/e2e/on-request-error/server-action-error-async/app/layout.js (added, +10/-0)
• test/e2e/on-request-error/server-action-error-async/app/write-log/route.js (added, +40/-0)
• test/e2e/on-request-error/server-action-error-async/instrumentation.js (added, +40/-0)
• test/e2e/on-request-error/server-action-error-async/next.config.js (added, +1/-0)
• test/e2e/on-request-error/server-action-error-async/server-action-error-async.test.ts (added, +76/-0)