Next.js Server Components and AbortController Signal Propagation

Answer to the questions

1. Does Next.js provide a built‑in signal that automatically triggers when a client disconnects during a Server Component render?

No. Next.js does not inject an AbortSignal into a server‑component render context. If you need to react to a client disconnect you must create an AbortController yourself and pass its signal to the APIs you want to cancel.

2. How should AbortError exceptions be handled to prevent unhandled promise rejections without interfering with the framework’s internal error boundaries?

Catch the AbortError in the async function that initiated the request and either return a graceful fallback or re‑throw a custom error that the component can render. Do not let the exception bubble unhandled; otherwise Next.js will surface its generic error page.

Confirmed facts (based on current Next.js behavior)

• Both Node.js and Edge runtimes support AbortController natively.
• When a client disconnects, the underlying HTTP layer may emit an abort event, but this event is not automatically forwarded to the JavaScript execution context of a server component.
• Aborting a fetch only cancels the network request; the surrounding async function continues unless you explicitly check signal.aborted or throw on abort.
• Uncaught AbortError results in an unhandled promise rejection and triggers Next.js’s internal error boundary, showing the default error page.

Practical steps for this case

1. Create an AbortController and pass its signal to fetch.

async function loadData() {
  const controller = new AbortController();
  const { signal } = controller;
  // optional: set a timeout to abort after 10 s
  const timeout = setTimeout(() => controller.abort(), 10_000);

  try {
    const res = await fetch('https://api.example.com/data', { signal });
    clearTimeout(timeout);
    return await res.json();
  } catch (err) {
    if (err.name === 'AbortError') {
      // graceful fallback – e.g., return empty data or a cached value
      return { data: [] };
    }
    // re‑throw other errors so Next.js can surface them if desired
    throw err;
  }
}

2. Listen for the abort event if you need to stop additional async work.

signal.addEventListener('abort', () => {
  // clean‑up or stop remaining tasks
});

3. Return a consistent UI when aborted. In a server component you can simply return null or a placeholder markup, which Next.js will render without invoking its error boundary.
4. Test in both runtimes. Run next dev with --experimental-edge and with a Node.js server to verify that the abort behaves the same. Log signal.aborted before and after the abort to confirm propagation.

What to check next?

To fine‑tune the solution, let me know which runtime you target for the component:

• Node.js (default server)
• Edge Runtime (via --experimental-edge or app/route.ts with export const runtime = 'edge')

Runtime differences can affect how the abort event is emitted and how long‑running tasks are cancelled.