mikicho
commented
11 months ago I discovered that by wrapping the second call with setImmediate, the likelihood of missing the timeout event significantly increases.
const { ClientRequestInterceptor } = require('@mswjs/interceptors/ClientRequest')
const http = require('http');
const interceptor = new ClientRequestInterceptor({
name: 'my-interceptor',
})
interceptor.apply();
interceptor.on('request', async ({ request }) => {
await new Promise(r => setTimeout(r, 1000));
request.respondWith(new Response('hello'))
});
http.get('http://example.text/', res => {
res.on('data', () => { })
res.on('end', () => {
console.log(1)
setImmediate(() => {
http.get('http://example.text/', { timeout: 10 }, res => {
res.on('data', () => { })
res.on('end', () => {
console.log(1)
})
})
.on('timeout', () => console.log('timeout'))
.on('error', e => {
console.log(e)
})
})
})
})
.on('timeout', () => console.log('timeout'))
.on('error', e => {
console.log(e)
})
I couldn't create a consistent example to reproduce the issue, but sometimes (once to 2-3 runs) the code fails to emit a timeout event when using an invalid URL (e.g. example.test). However, it emits the event every time when using nowhere.com.
It reproduces only after at least one request prior to the request with the timeout.
My best guess is that something within Node aborts the request with ENOTFOUND before it checks the timeout.
logs: