What results in a ClientRetryPlugin retry?

[yinghaochan]

The docs state that:
The Client Retry Plugin enables retrying client calls when errors occur.

However, I'm hitting a timeout error in Node22 that does not get retried:

    TypeError: fetch failed
    at node:internal/deps/undici/undici:13510:13
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async LinkFetchClient.call (file:///.../node_modules/@orpc/client/dist/adapters/fetch/index.mjs:28:27)
    at async file:///...l/node_modules/@orpc/client/dist/shared/client.gGlqtcwN.mjs:52:28
    at async file:///.../node_modules/@orpc/client/node_modules/@orpc/shared/dist/index.mjs:484:14
    at async Proxy.procedureClient (file:///.../node_modules/@orpc/client/dist/index.mjs:68:12)
    at async main (.../src/main.js:132:29)
caused by: AggregateError [ETIMEDOUT]: 
    at internalConnectMultiple (node:net:1134:18)
    at internalConnectMultiple (node:net:1210:5)
    at Timeout.internalConnectMultipleTimeout (node:net:1742:5)
    at listOnTimeout (node:internal/timers:590:11)
    at process.processTimers (node:internal/timers:523:7)

Is there a set of errors that does / doesn't result in retries, and maybe (as a potential feature request) making it customisable?

[dosubot[bot]]

The ClientRetryPlugin decides whether to retry based on the shouldRetry function and the configured retry count—there isn’t a hardcoded list of error types that are retried or skipped by default. By default, retries are disabled unless you set a retry count, and shouldRetry defaults to always true, but you can override it to inspect error properties and customize which errors trigger a retry (for example, by checking error codes or names) source.

Timeout errors like ETIMEDOUT in Node22 (often from Undici's fetch) are not retried by default, likely because the default shouldRetry logic doesn’t specifically handle them source. You can make retries more granular by providing a custom shouldRetry function that matches on error details, so you can enable retries for timeouts or any other error type you need.

The plugin also lets you configure retry delays and hooks for custom logic on each retry attempt. If you want to handle specific errors like timeouts, customize shouldRetry to check for those error codes or messages.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[yinghaochan]

Timeout errors like ETIMEDOUT in Node22 (often from Undici's fetch) are not retried by default,

shouldRetry is already always true by default

[dosubot[bot]]

Retries only happen if the retry count is set to a positive value in your client context—by default, it's 0, which disables retries, even if shouldRetry is always true. Make sure your configuration includes something like retry: 3 (or any number greater than zero) alongside your shouldRetry function to enable actual retry attempts. There’s no hardcoded exclusion for error types like ETIMEDOUT; as long as the error is thrown and caught by the plugin, it should be retried if both conditions are met. If you’re still not seeing retries, it’s worth logging the error object to confirm it’s reaching the retry logic as expected, since some runtime errors (especially from Undici/fetch) might be wrapped or propagated differently in Node22.
Docs and implementation details
Source code

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[unnoq]

There no exception error list, but retry plugin run after user's interceptor - if your interceptor throw error before hit plugin - retry will never happen. But if everything correct, please report a bug with minimal repro.

[yinghaochan]

Thanks @unnoq. Does this mean that the onError interceptor should re-throw so the retry happens?

const link = new RPCLink<ORPCClientContext>({
  url,
  headers: () => ({
    authorization: `Bearer ${process.env.ORPC_TOKEN}`,
  }),
  plugins: [
    new ClientRetryPlugin({
      default: {
        shouldRetry: true,
        retry: 0,
        retryDelay(o) {
          return (o.lastEventRetry ?? 1000) * 2;
        },
        onRetry(options) {
          logger.error(options, 'Client Retry');
        },
      },
    }),
  ],
  eventIteratorKeepAliveEnabled: true,
  eventIteratorKeepAliveInterval: 5000, // 5 seconds
  eventIteratorKeepAliveComment: 'ping',
  // fetch: <-- provide fetch polyfill fetch if needed
  interceptors: [
    onError((error) => {
      logger.error(error);
      // re-throw error?
    }),
  ],
});

[unnoq]

@yinghaochan no, onError always rethrow underhook

[yinghaochan]

@unnoq Thanks! After your replies, I found the error on my side.