How should loader cancellation propagate into createServerFn handlers?

[kuldeeprajput-dev]

TanStack Router loaders receive an AbortSignal, and createServerFn callers also accept signal:

loader: ({ params, abortController }) =>
  getReport({
    data: { id: params.id },
    signal: abortController.signal,
  })

However, the signal is not exposed in the typed .handler(({ data }) => {}) context.

Should the handler use getRequest().signal, or is middleware the supported way to access it? Also, during SSR and client navigation, does cancellation stop only the RPC request, or does it notify the running server handler so downstream database/API work can be cancelled?

Docs: [Server Functions – Request Cancellation](https://tanstack.com/start/latest/docs/framework/react/guide/server-functions#request-cancellation)

[MentalOfCrow]

getRequest().signal is the direct option inside the handler. Function middleware is useful when several server functions need shared cancellation behavior, but it is not required just to obtain the signal.

TanStack’s own React Start E2E fixture currently uses this exact pattern:

import { getRequest } from "@tanstack/react-start/server"

const getReport = createServerFn().handler(async () => {
  const { signal } = getRequest()

  return fetch("https://example.com/report", { signal })
})

The relevant fixture reads getRequest().signal, installs an abort listener, clears its timer, and rejects when aborted: e2e/react-start/server-functions/src/routes/abort-signal/$method.tsx. The corresponding Playwright test aborts the client-side controller and expects the server-side operation to report an abort: server-functions.spec.ts.

Function middleware also exposes a typed signal: AbortSignal in its server options, so middleware is a reasonable abstraction if you want to place the signal in shared context or apply the same cleanup policy across handlers: createMiddleware.ts.

The important distinction is that cancellation is propagated, not magically applied to every downstream task:

• aborting the createServerFn call aborts the RPC request;
• the server observes that through the current Request.signal;
• fetch(..., { signal }) and other AbortSignal-aware APIs can then stop their work;
• a database driver or long-running promise that never receives/listens to the signal will continue unless you use that driver’s own cancellation mechanism.

So for a loader, passing abortController.signal at the call site and then reading getRequest().signal in the handler is the intended end-to-end shape. I would only introduce middleware when you need to reuse the behavior, not merely to access the current request signal. As always, verify the deployment adapter preserves request-abort propagation, especially behind a proxy.