retry fetch failed error

is there a simple flag to have ConvexHttpClient retry what seems to be a connection timeout error?

node:internal/deps/undici/undici:11730
    Error.captureStackTrace(err, this);
          ^
TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11730:11)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at runNextTicks (node:internal/process/task_queues:64:3)
    at process.processImmediate (node:internal/timers:449:9)
    at async ConvexHttpClient.action (/home/node/app/node_modules/convex/dist/cjs/browser/http_client.js:228:22) {
  cause: ConnectTimeoutError: Connect Timeout Error
      at onConnectTimeout (node:internal/deps/undici/undici:6869:28)
      at node:internal/deps/undici/undici:6825:50
      at Immediate._onImmediate (node:internal/deps/undici/undici:6857:13)
      at process.processImmediate (node:internal/timers:478:21) {
    code: 'UND_ERR_CONNECT_TIMEOUT'
  }
}

node:internal/deps/undici/undici:11730
    Error.captureStackTrace(err, this);
          ^
TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11730:11)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at runNextTicks (node:internal/process/task_queues:64:3)
    at process.processImmediate (node:internal/timers:449:9)
    at async ConvexHttpClient.action (/home/node/app/node_modules/convex/dist/cjs/browser/http_client.js:228:22) {
  cause: ConnectTimeoutError: Connect Timeout Error
      at onConnectTimeout (node:internal/deps/undici/undici:6869:28)
      at node:internal/deps/undici/undici:6825:50
      at Immediate._onImmediate (node:internal/deps/undici/undici:6857:13)
      at process.processImmediate (node:internal/timers:478:21) {
    code: 'UND_ERR_CONNECT_TIMEOUT'
  }
}

It seems some mutations were dropped when this error occurred. This came up while I was performance testing, I haven't seen in production.

4 Replies

ian•13mo ago

Out of curiosity, could this use case be using the ConvexClient instead? That one has a websocket and manages connections, serialization, etc more robustly. The http client just makes a fetch per call, so each mutation can succeed / fail independently or even arrive out of order if the network struggles For http I’d suggest adding your own retries around queries, but only on mutations you can guarantee idempotence on Due to http limitations, it could succeed in mutating but seem to fail on the client

wjarjouiOP•13mo ago

we're running this from a nestjs backend. I think we went with ConvexHttpClient for that reason, would you recommend the ConvexClient also for a nestjs backend? @ian just bumping the above^

ian•13mo ago

Yeah I think http is the right fit for SSR. Hopefully the network blips are very transient. For queries it’s totally fine to wrap it in a retry on network errors if it’s happening too often. During performance testing maybe the network was clogged is my only thought otherwise Ah I thought you had mistyped 🙈 If it’s a long-lived thing then the websocket client is the best bet But note that you set auth on it per-client, so it still might still want to be per-user-request. Establishing a websocket for a few messages might be overkill? Maybe give it a shot and see how it works for you

wjarjouiOP•13mo ago

This one is actually not per user and can be long-lived. Good to know your thoughts, for science; we're killing that backend completely to shift to convex (🙌) so won't be using either client pretty soon

retry fetch failed error

Did you find this page helpful?