Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (0f4d041) 93.61% compared to head (18bf2ab) 93.61%.

❗ Current head 18bf2ab differs from pull request most recent head fe5e069. Consider uploading reports for the commit fe5e069 to get more accurate results

@@           Coverage Diff           @@
##           master    #1974   +/-   ##
=======================================
  Coverage   93.61%   93.61%           
=======================================
  Files          28       28           
  Lines        3757     3759    +2     
=======================================
+ Hits         3517     3519    +2     
  Misses        240      240           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Hello, may I know what's the use case for this? I don't think making the version number user configurable is a good idea.

Hello Selwin. Assume one has a request receiving API, and multiple workers. The receiving API receives requests for jobs, these are pushed into RQ and the workers consume and execute jobs. Assume the receiving API is run in one container, the Redis database as a separate container, and each worker (multiple of them) is also run as a separate container (these can be all on a single server or distributed over multiple servers).

Assume all workers perform the same job. Code changes to the workers code base (resolved bugs, optimisations, etc.) that are unrelated to the RQ version are important, and there are occasions when multiple worker versions will coexist (e.g. testing if a bug fix resolves the issue, ...). The worker version (e.g. the version of the job execution codebase, not the RQ version) is in these cases important. When multiple versions of workers coexist, the worker's version is also important from the job's perspective (e.g. the worker's - job execution codebase - version may affect the "quality" of the result/output).

Making the worker version configurable, allows developers to pass the information about the specific worker version (e.g. version of the job execution codebase) that is running in an individual container to the receiving API (if they choose so), without resorting to worker class overrides. Note that the PR only relaxes the restriction; if the developers do not choose to override the version, the current behaviour is left unchanged, if they do, the RQ version is still available, but under a more descriptive variable worker.rq_version.