Support a request "error" event listener

[marcelkottmann]

We are using the interceptor in our application not for mocking, but for intercepting all requests made to (trace/debug) log all requests and responses and some metadata request id, duration, ...

We had the problem that some of the requests fail due to network issues ("socket hang up", "connection refused", ...) that lead to an error instead of an actual response.

The problem is that there is no event that is available to listen for an error like that. Is there any possibility to either implement an "error" listener or are there any workaround to get the error in the interceptor?

[kettanaito]

Hi, @marcelkottmann. Thanks for raising this.

What would classify for the "error" event? Any request error?

I can imagine a usage like this:

interceptor.on('request:error', ({ request, cause }) => {
  console.log('request failed due to:', cause)
})

Where cause is the original error that resulted in the request's failure.

I think people would want for the request:error event to maintain the request's context so they would be able to retry it. Interceptors currently doesn't support affecting requests at this stage. Request error implies the request was passthrough—it hasn't been handled in the request event. I see this new event as readonly.

How does that compare to your vision of this event and its usage?

[marcelkottmann]

Hi @kettanaito ,

What would classify for the "error" event? Any request error?

I would like to be as generic as possible, that means if the underlying request-implementation (e.g. fetch) throws an error (i.e. rejects the promise) this error should be captured and be provided to the listener.

I can imagine a usage like this:

interceptor.on('request:error', ({ request, cause }) => {
  console.log('request failed due to:', cause)
})

Where cause is the original error that resulted in the request's failure.

Thats exactly how I also would imagine this api.

I think people would want for the request:error event to maintain the request's context so they would be able to retry it. Interceptors currently doesn't support affecting requests at this stage. Request error implies the request was passthrough—it hasn't been handled in the request event. I see this new event as readonly.

It feels like I don't fully understand this section, but in case of an error event I wouldn't strive for having retry functionality inside the interceptors listener. Retry logic is the responsibility of the code that originally requests something.

How does that compare to your vision of this event and its usage?

That looks very promising thank you!

[kettanaito]

I think this should be possible. The request:error event will be dispatched in different situations based on the interceptor:

• fetch, the response promise has rejected;
• ClientRequest, the error event has been emitted (that should cover socket errors too);
• XMLHttpRequest, the error event gets dispatched.

One thing to keep in mind is to separate request errors from any exceptions happening during the request listener phase. Basically, make sure this new feature and the unhandledException don't intersect.

[GravlLift]

I'm also interested in this feature, for a similar reason as OP, though specifically I'm looking for a way to correlate requestIds with these errors. So maybe a small addition to the proposal?

interceptor.on('request:error', ({ request, cause, requestId }) => {
  console.log('request failed due to:', cause)
})