Update some more tests relying on timeouts #341
Conversation
In addition it's probably better to use a t.setTimeout(..) than assertion for a timeout because it will come with a clear and informative error message.
Avoid relying on node being able to execute its setTimeouts within a reasonable time to account for the low performance VMs of the tests environments.
|
wooow! Good spot. Could you fix retimer? Another way might be to just drop its usage. The cost of allocating a timer almost disappeared in latest Node.js |
|
It makes sense to update retimer as it does add some functionality over the standard setTimeout(). |
nherment
changed the title
|
@mcollina the Pr has been updated with the latest retimer and the code updated. |
| const opts = lazyServer.address() | ||
| opts.pipelining = 2 | ||
| const client = new Client(opts) | ||
| let count = 0 | ||
|
|
||
| client.on('response', (statusCode, length, duration) => { | ||
| t.equal(statusCode, 200, 'status code matches') | ||
| t.ok(duration > 500 && duration < 800) | ||
| t.ok(duration > delayResponse, `Expected response delay > ${delayResponse}ms but got ${duration}ms`) |
There was a problem hiding this comment.
FYI the original reason for checking if duration < 800 was this.
our calculations were giving ~half results, so not checking if it takes less than 600ms might not catch if the calculations in future break and start giving 2x time. We can increase it to 700 if builds start to fail.
I know it wasn't the right fix and there should be a more predictable way to assert this but removing the upper limit check brings the risk I explained in the comment.
There was a problem hiding this comment.
@nherment could you handle this?
There was a problem hiding this comment.
Yes, I'll add a unit test for these calculations.
There was a problem hiding this comment.
@salmanm could you please point me to the 'calculations' you are referring to?
The code around the delayed response is pretty straightforward and I don't see anything that I would classify as calculations.
@mcollina this should help further.
However, I don't like the fix here because as a user of
httpClientI would expect forclient.destroy()to work regardless of when it is called. In the current implementation,client.destroy()will not work as expected if invoked synchronously in a timeout handler. It does not clear the retry mechanism of thehttpClient.I think the "right" fix consists in using a different version of
retimerthat allows to reset the timer after it has been triggered. This way there is no need to change the instance of retimer within thehttpClient.Cf.
autocannon/lib/httpClient.js
Line 73 in f8b598e