Created by: Rua-Yuki
This PR resolves failures in the repeatable job test suite brought about by upgrading ioredis
to 4.19.0+, as mentioned in the comments for https://github.com/OptimalBits/bull/commit/6fe29283e85a64c07586fe8463de065ae7480513 and https://github.com/OptimalBits/bull/issues/758.
The precise change in ioredis
which yields breakage is the introduction of a new script cleanup helper interval, intended to periodically purge a dictionary used for tracking scripts loaded for the purpose of pipelining. See here, or observe the excerpt below.
this._addedScriptHashesCleanInterval = setInterval(() => {
this._addedScriptHashes = {};
}, this.options.maxScriptsCachingTime);
Nothing is intrinsically wrong with what ioredis
has done here. We only see breakage within the Bull tests due to a chance interaction with the new cleanup interval, brought about by extremely taxing usage of sinon
.
During the test setup phase, sinon
is used to spoof timing functions, applying a base time equivalent to the Unix epoch.
https://github.com/OptimalBits/bull/blob/dbc08f23e93147c5c6b2b04fdad5a0c92d746654/test/test_repeat.js#L21
Within some tests, the same sinon
clock is advanced by massive amounts at once (over 47 years).
https://github.com/OptimalBits/bull/blob/dbc08f23e93147c5c6b2b04fdad5a0c92d746654/test/test_repeat.js#L200-L201
These clock.tick(...)
calls result in a punishing number of executions (around 25 million) of the aforementioned interval. This all takes quite a while, leading to timeouts in the end, and ultimately being the root of test failures.
The solution for this thankfully appears to be a simple one: merely swapping out clock.tick
with clock.setSystemTime
.