You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug :INFO keys do not remain in redis when a job is first created - however they do remain after attempting to enqueue an identical job runs into an existing lock, and then show in the web UI.
Expected behavior
With lock_info enabled, the INFO key is created when the job is created and remains until the lock expires or is deleted.
Current behavior
The INFO is set to expire in 1000 msec when a lock is created. If the job is called a second time, the :INFO key is created in a persistent manner.
Thanks for the awesome gem and this is not a huge issue as it is debugging info, but does seem to be a bug. From reading the code, I'm not sure if lock.lua should set the TTL or not or if that is a concern for the ruby code to update that after. Here's some debugging information which shows what is happening:
Enqueue the job for the first time & print some debug info:
The problem is that your particular lock is actually two different ones. It first locks when the client pushes the job to the queue, when the server picks it up from the queue it first unlocks that one and then creates a different lock for just around your worker doing the work.
I agree that information is lost this way and that it would be cool to keep the lock info around until the job is either unlocked or completed.
Describe the bug
:INFO
keys do not remain in redis when a job is first created - however they do remain after attempting to enqueue an identical job runs into an existing lock, and then show in the web UI.Expected behavior
With lock_info enabled, the INFO key is created when the job is created and remains until the lock expires or is deleted.
Current behavior
The INFO is set to expire in 1000 msec when a lock is created. If the job is called a second time, the
:INFO
key is created in a persistent manner.Worker class
Additional context
Thanks for the awesome gem and this is not a huge issue as it is debugging info, but does seem to be a bug. From reading the code, I'm not sure if
lock.lua
should set the TTL or not or if that is a concern for the ruby code to update that after. Here's some debugging information which shows what is happening:Enqueue the job for the first time & print some debug info:
output from monitoring redis:
enqueue the job again:
redis monitoring output:
The text was updated successfully, but these errors were encountered: