Currently trying this code to implement a 1 millisecond timeout. I expect all requests to be cancelled, but I can see responses are still being received successfully, AFTER the cancel request is called.

Is this because the code is expecting the req.cancel() to propagate an error... ???

const fetchRequest = new ethers.FetchRequest(network)
const timeoutMS = 1
fetchRequest.preflightFunc = async (req: ethers.FetchRequest): Promise<ethers.FetchRequest> => {
  ;(req as any).timeoutRef = setTimeout(() => {
    try {
      req.cancel()
    } catch (error) {
      console.error(`Cancelled request after ${timeoutMS.toLocaleString()} milliseconds`)
    }
  }, timeoutMS)
  return req
}

// intercept the response
fetchRequest.processFunc = async (
  req: ethers.FetchRequest,
  resp: ethers.FetchResponse
): Promise<ethers.FetchResponse> => {
  if ((req as any).timeoutRef) {
    clearTimeout((req as any).timeoutRef)
  }
  // ... the response still comes through successfully, and is handed back to waiting promise, despite a 1 millisecond timeout
  return resp
}

The Signalling was added as a stub to add in the future. I can look at this now.

Each platform has its own support for cancelling requests, and some are actually honoured (i.e. stop the request and reclaim socket resources) while some simply discard the results when they finally arrive. It will still be up to the platform to decide how to handle this, but at the very least, Ethers should provide a standard and consistent experience.

I needed the same thing with contract function calls. It's not just about cancelling requests after a specific timeout but it's also useful for cleanups in frontend. I saw some signal implementations for request cancellation but seems like they're for internal usages.

It'd be nice if we get a similar usage like fetch, axios etc. Passing an AbortController.signal property.

I had a lot of ideas I tried out for v6, but it’s hard because of the way TypeScript and Promises work together.

But I have some ideas for v7 to try out, which will be that each provider method (and Contract overrides) will accept an AbortController, as well as a customData, which can be included in all errors emitted and more importantly in the getUrlFunc so additional data can be passed into custom fetching.

Any other ideas for options to pass in?

No need to pass all AbortController object. I believe passing an AbortSignal should be enough. So in the application side developers can just use it for timeout and cleanup purposes:

const abortController = new AbortController()

// which would internally listen for `signal.addEventListener('abort', () => ...)` and cancel the requests
contract.func(...args, { signal: abortController.signal })

setTimeout(() => abortController.abort(), 3000) // abort after 3 seconds

Same for unmounts in frontend, React for example:

useEffect(() => {
  const abortController = new AbortController()
  
  // which would internally listen for `signal.addEventListener('abort', () => ...)` and cancel the requests
  contract.func(...args, { signal: abortController.signal })

  return () => abortController.abort() // abort if component is unmounted
}, [])

Oh, sorry. Yes, that’s what I meant. There is an Ethers object for that, so that the interface is the same between platforms. :)

There is a bug in utils/geturl.ts: timeout event from socket is ignored but must be handled manually.

request.setTimeout(timeout, function() {
    request.abort();
});