v2.8.0

• To use ioredis instead of Node Redis, pass the following option to Bottleneck: { datastore: "ioredis" }. ioredis supports Redis Cluster and Redis Sentinel
• To use Redis Cluster, pass the following options to Bottleneck: { datastore: "redis", clusterNodes: [nodes] }. See the ioredis cluster docs and the Bottleneck docs for more information

v2.7.2

• Fixed an issue where some limiter options were not properly marked as nullable.

v2.7.1

• Fixed a Clustering issue where limiters would sometimes fail with a NOSCRIPT error.

v2.7.0

• All limiters within a Group now share the same Redis connection. Standalone limiters continue to have their own limiters.
• Added the timeout option to limiters to allow freeing Redis state after a period of inactivity.
• Fixed a bug when using Groups, Clustering, highWater and job expirations.

v2.6.0

• Added support for passing job options to a wrapped function.

const wrapped = limiter.wrap(fn);
wrapped.withOptions(options, arg1, arg2);

v2.5.1

• Fixed a memory leak where autogenerated job IDs would progressively get longer and take more memory. All users are advised to upgrade to this version. There are no breaking changes.

v2.5.0

• Added the stop() method, which allows safely stopping a limiter and executing work once completed. See Readme.

v2.4.0

• Jobs with duplicate IDs are now rejected instead of throwing an exception.

v2.3.1

• Fixed a warning when using Webpack v4
• Relaxed the requirement to return a promise from .schedule().

counts(), jobStatus()

This release brings visibility into the status of limiters and jobs.

• Added .counts() which returns an object with the number of jobs in every stage of their lifecycle.
• Added .jobStatus(). It takes a jobId and returns the status of that job.
• Added trackDoneStatus, a new limiter option, defaulted to false. Setting it to true will make your limiter keep track of Done jobs in .counts() and .jobStatus(). It is false by default, since it involves remembering every jobId that has ever reached the Done stage, which could lead to a memory leak if your application processes tens or hundreds of millions of jobs between restarts.