Closed kettanaito closed 2 months ago
@mikicho, I think you should know about the difference I outlined above. See if Nock understands those two different timeouts and treats them the same. It's rather tricky and undocumented, and I wouldn't be surprised if it didn't.
I also suspect that AbortSignal.timeout(n)
will act similarly to setting a timeout. But I expect it to result in the "abort" event on the request.
See if Nock understands those two different timeouts...
Nock is aware of these two, and it actually uses this value for throwing a timeout error immediately if the timeout is bigger than what is defined in the interceptor. This is a nifty feature that MSW (or mswjs/intrceptors) should consider.
P.S: when I tried to implement this for the fetch
API, it turned out that the delay connection
feature doesn't make much sense because Fetch doesn't provide this level of granularity.
This is a nifty feature that MSW (or mswjs/intrceptors) should consider.
Interceptors do not decide that for you so they shouldn't do anything on top of what Node.js does. Node.js doesn't do anything to the request, not even destroys it. It only emits the timeout
event for you do handle that timeout in whichever fashion you want. I think it should stay that way.
delay connection feature doesn't make much sense because Fetch doesn't provide this level of granularity.
Yep, I remember that!
Interceptors do not decide that for you so they shouldn't do anything on top of what Node.js does
Nock does not change Node.js behavior here:
timeout
event.Users still can use fake timers instead, but Nock give this OOTB which is nice.
Timeout was supported as-is, I've only added automated tests.
In the context of Interceptors, this difference is important because we can reproduce
http.request(u, { timeout: n })
by making the request listener take more time than the specified timeout, but thehttp.request(u).setTimeout(n)
must receive either a mocked or bypassed response headers before it's even added (socket connect emitted).Also adds a
this.destroyed
check inpassthrough()
andrespondWith()
so they'd have no effect if the socket has been destroyed (e.g. aborted or timed out).