Cancel HTTP requests initiated by a transport

[0xOlias]

It would be great to programmatically cancel in-flight HTTP (or WebSocket) requests initiated by a transport. Best case, we could cancel individual requests, but it would still be very useful if it were only at the transport level (effectively a "shutdown"/cleanup function for the transport).

I experimented with passing an AbortSignal to the http transport fetchOptions. This seems to work, but it looks like providing this option disables the timeout logic. This could probably be fixed using AbortSignal.any(). But, this would only work for HTTP transports and only at the transport granularity, not for individual requests.

[tmm]

Just commenting that this would be used in Wagmi too (have a TODO over there). Need to figure out a good API.

[0xOlias]

Couple quick ideas:

1. Add a signal option to EIP1193RequestOptions.

export type EIP1193RequestOptions = {
  // The base delay (in ms) between retries.
  retryDelay?: number
  // The max number of times to retry.
  retryCount?: number
+  // An AbortSignal to be used by interruptible operations made during the request (e.g. `fetch`).
+  signal?: AbortSignal
}

2. Add the same parameter to ~every action, similar to how most actions accept blockNumber and blockTag.

[jxom]

1. Makes sense.

2. Makes sense. Should this be encapsulated into a separate property (e.g. internal)? I get a bit worried that consumers may get confused of extraneous properties, and typically want to avoid a scenario where we may want to extend this pattern for other things which could lead to dozens of properties (and fatiguing the API).

[0xOlias]

Yup, understand the hesitation.

I could see the new parameter being requestOptions?: EIP1193RequestOptions. This would also make it possible to override retryCount and retryDelay per-request (and maybe timeout too). I'm not sure what additional options you could see creeping in here, but this name/type seems safer than a catch-all like internal.

Now, when a user creates a custom transport, their request function could/should implement the request-specific overrides:

const transport = custom({
  async request({ method, params }, { signal, retryCount, retryDelay }) { 
    // ...
    const response = await fetch(url, { signal })
  }
})

Actions like watchEvent make more than one request, which is a complication. Perhaps there is already a pattern for this via createFilterRequestScope? If these actions accept one signal and share it for all requests, they would suffer the same problems as transport-level signals (read on).

I don't think it's a good idea to support passing signal in the http transport fetchOptions parameter. I tested this quite a bit and ran into several issues:

• On Node.js, this leads to the annoying MaxListenersExceededWarning log if you make more than 10 (or 100, depending on your Node version) simultaneous requests.
• Once you abort the signal once, you can't abort it again, which makes the transport somewhat stateful 🤮

Per-request cancellation would make it possible to do batch cancellation safely in userland with one AbortController per request. The fetchOptions type already omits body, would be easy to also omit signal.

[0xOlias]

@tmm @jxom Would you be open to a PR with these changes as a starting point?

1. Add { signal?: AbortSignal } to EIP1193RequestOptions type
2. Add { requestOptions?: EIP1193RequestOptions } parameter to most actions, which would serve as an override to any request options specified (or defaulted) at the transport-level?
3. Update http transport to use requestOptions.signal

FWIW, it intuitively makes sense to me that most actions would accept a requestOptions parameter, and naming it that way would avoid a catch-all/slippery slope.

[jxom]

I am happy with that.

[fubhy]

I'm glad this is getting tackled. I closed #1239 as a duplicate.

This would be really handy to embed viem fully into the Effect interruption model :-)

[Holybasil]

how can I find out the latest status of this feature, such as the expected release date?

[niklasp]

+1