Release v0.7.7

Minor changes:

• Bump redigo
• Separate benchmark dependencies

Release v0.7.6

Minor changes:

• Update webui dependencies

Release v0.7.5

Important changes:

• Introduce redis replication wait option for enqueuer (#30)

Minor changes:

• Handle redis.ErrNil for Queues's latency (#32)

Release v0.7.4

Important changes

• Handle bad JSON input in Args and BusyWorker components (#24)

Release v0.7.3

Important changes

Display job arguments in a new component that supports syntax highlighting, collapsing properties and copying properties in WebUI (#21)

Additional changes:

• The job arguments display component also checks for a root level base64 encoded JSON property named payload, iff present, it tries to unwrap it and display.

Release v0.7.2

Important changes

Display additional stats on queues page in WebUI (#17)

Additional stats displayed:

• lock_count
• max_concurrency

Release v0.7.1

Important Changes

Run go generate to update embedded assets (f4d3bd7)

Release v0.7.0

Important Changes

Declare module as github.com/gojek/work (#16)

Usage

The module is backward compatible with github.com/gocraft/work. To switch to this module, simply replace github.com/gocraft/work with github.com/gojek/work in Go source files and run go get:

go get github.com/gojek/work

Release v0.6.1

Important Changes

Usage

go get github.com/gocraft/work && \
  go mod edit -replace github.com/gocraft/work=github.com/gojek/[email protected] && \
  go mod tidy

Worker pool started check

Expose work.(*WorkerPool).Started which can be used to check if the worker pool has been started and is running.

Release v0.6.0

Important Changes

Usage

go get github.com/gocraft/work && \
  go mod edit -replace github.com/gocraft/work=github.com/gojek/[email protected] && \
  go mod tidy

Refresh Node.js dependencies for WebUI (99f237a).

This fixes multiple security vulnerabilities.

Requeue in progress jobs and clean stale lock info on stop (#1).

In case there is a failover with a Redis Sentinel cluster with data loss, there can be stale lock information which can cause job processing to be stuck if the max concurrency limit is reached. Therefore, the jobs which were in progress are re-enqueued, and the stale lock info for the worker pool is cleaned up.

NOTE: This is only necessary for worker instance with Sentinel Redis setup, in conjunction with max concurrency being defined for jobs.

⚠️WARNING: This can result in jobs being executed multiple times as we re-enqueue the jobs from in-progress queue. It is possible that the job was actually processed successfully by the worker, but the change for removing from in-progress queue was lost.

Expose lock count & max concurrency for each job (#2)

Added to the queue info accessible from work.Client.Queues(). Useful for alerting when lock count is consistently equal to the max concurrency possibly indicating that stale lock count is resulting in jobs not being picked up.

For the cleanup to be thorough, work.(*WorkerPool).Stop would need to be called on each worker pool instance.