v1.0.0-rc2

This is a release candidate for v1.0.0.

This release includes an upgrade to the internal go-redis version, allowing CurlyQ to accept go-redis clients with more advanced configuration options.

v1.0.0-rc1

This is a release candidate for v1.0.0.

This release introduces a guarantee that jobs added to the queue will always be consumed in FIFO order. Previously, the mechanism used to detect the presence of new jobs on the queue had the side-effect of rotating jobs from the back of the queue to the front. While unlikely, it was possible for this procedure to repeatedly push the same jobs back from the front of the queue, preventing them from being consumed indefinitely. The logic for detecting new jobs has been modified so that it no longer operates against the queue, eliminating this issue. (Please note that processing order is still not guaranteed, as jobs are executed concurrently once consumed.)

Other changes:

• ErrJobAlreadyExists is now returned when trying to enqueue or schedule a job that is already present in Redis. Previously, no error was returned. This API change allows clients to detect if duplicate jobs have been scheduled and handle the situation as needed.
• The dependency list was pruned of unneeded libraries.

v0.4.0

This release integrates an exponential backoff procedure into all of the consumer's internal processing loops so that they will not attempt to poll Redis in tight loops if they encounter network failures. It also exposes the ability to automatically trigger a critical error and abort after a maximum number of such failures. The default behavior is still for the processing loops to attempt to reconnect indefinitely.

Other changes:

• The maximum backoff between job retries is now configurable. The default parameters for retries have been modified so that jobs will now be retried for roughly 2 weeks before being killed.
• DefaultLogger is now less verbose by default. A LoudLogger type has been added for easy debugging.
• A race condition was fixed where consumers might fail to register themselves before retrieving jobs in cases of intermittent network failure.
• Various performance enhancements and increased test coverage.

This is expected to be the final feature release before v1. Future pre-releases will focus on bug fixes, usability enhancements, and documentation improvements.

v0.3.0

This release adds logic to listen on changes to data stored in Redis so that new jobs can be detected and processed as soon as they are added to the queue. It also addresses several minor issues with the tests and refactors them so that they are easier to follow, particularly when testing concurrent behavior.

v0.2.0

This release implements logic to address failure scenarios related to transient network or Redis errors. Previously, if a consumer failed to advance a job to its next state but then successfully registered a heartbeart, it was possible for it to retain ownership of that job indefinitely. Now, if a consumer encounters an error when trying to retry, kill, or acknowledge a job, it will immediately abort in order to ensure the job can be transferred to another consumer in a timely fashion.

This release also exposes a configurable logger interface and fixes some concurrency-related bugs.

v0.1.0

Initial release.