AbortController vs. Built‑in Timeout: Simplicity or Control?

Direct Answer

Use the built-in timeout option when you only need to bound the response latency seen by the caller. Switch to AbortController (or a polyfill) when the action performs I/O — HTTP calls, database queries, file streams — that must be terminated to free server-side resources. The two mechanisms solve different problems: timeout protects the client; AbortSignal protects the server.

How Each Mechanism Behaves

Built-in timeout

• Implemented as a Promise.race between the action promise and a timer.
• When the timer fires, the caller's promise rejects with a MoleculerError (code ETIMEDOUT).
• The action handler continues executing until it naturally resolves or throws; no signal reaches the handler code.

AbortController / AbortSignal

• Requires the broker (or a middleware) to create an AbortController, pass its signal to the action, and call controller.abort() on timeout or client disconnect.
• The action must listen for signal.addEventListener('abort', …) or pass the signal to APIs that support it natively (fetch, axios with signal, pg query streams, etc.).
• If the underlying library honors the signal, the I/O operation is cancelled at the OS/network level, releasing sockets, query slots, and memory immediately.

Decision Checklist

1. Does the action perform cancellable I/O? If no (pure CPU work, in-memory transforms), timeout is sufficient.
2. Node version ≥ 15.4.0? Native AbortController is stable from 15.4; Node 16+ is safe. For older runtimes, add the abort-controller polyfill.
3. Do your I/O libraries accept AbortSignal? Verify fetch, database drivers, or HTTP clients you use actually abort on signal. If they don't, AbortController buys you nothing.

Minimal Implementation Pattern (Node 16+)

// Middleware to inject signal and abort on timeout
module.exports = {
  name: 'abortable-timeout',
  localAction(next) {
    return (ctx) => {
      const controller = new AbortController();
      const { timeout = 5000 } = ctx.action;
      const timer = setTimeout(() => controller.abort(), timeout);
      ctx.params.$abortSignal = controller.signal;
      return next(ctx).finally(() => clearTimeout(timer));
    };
  }
};

// Action using the signal
module.exports = {
  name: 'posts',
  actions: {
    fetchExternal: {
      timeout: 5000,
      async handler(ctx) {
        const res = await fetch('https://api.example.com/data', {
          signal: ctx.params.$abortSignal
        });
        return res.json();
      }
    }
  }
};

Verification Steps

1. Run node -v and confirm ≥ 15.4.0 (or polyfill loaded).
2. Deploy a test action that logs start, waits 30 s, logs end. Call it with timeout: 1000. Observe that end still appears — proving timeout alone doesn't stop work.
3. Repeat with the middleware above and fetch to a slow endpoint; confirm the TCP connection closes at the timeout mark (watch with netstat or server logs).

One Missing Diagnostic Detail

What is the exact Node.js version in your production environment? If it is < 15.4.0, you must decide whether adding the abort-controller polyfill is acceptable before adopting AbortSignal across actions.