-
-
Notifications
You must be signed in to change notification settings - Fork 277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jobs not being executed anymore?? #65
Comments
Hmm for us it is the opposite. Before 3.0.10 job uniqueness didn't work. Is it possible that your redis hasn't been cleared up on a bunch of lock keys? |
Having the same issue. With a completely empty Redis instance, even though we're using mock_redis. Job arguments are a record ID that can't be a duplicate, because it's a record primary key. Using inline testing, the worker that has unique enabled never runs. I had to downgrade to 3.0.2, because any newer version fails consistently. Also, since we're using mock_redis, the contents of any Redis instance should not matter, should they? Please don't think that this issue is resolved; it seems that those like @emas80 have just locked their version to 3.0.2 and left it, like I'm about to do. We'll try to write up a test case. |
I'm not sure this problem will ever truly be solved. In our situation I am actually using the database to force uniqueness but in my case I need to never ever be able to re-run certain jobs. Maybe mock redis was a bad idea... Anyway, give me a test case and lets fix it once and for all. |
Open a new issue with a failing test if this is still a problem. |
Hi, upgrading the gem from 3.0.2 to 3.0.9 seems creating issue while executing some kinds of jobs.
I don't know how to build a simple test case to replicate it. It happens every time we are executing a particular job, but this job is not different from the others, and it doesn't even have the unique attribute so it should be totally ignored.
I mean, if the issue is present with this job, than it should be present with all the jobs...
The job contains an options object with { data => { match_id => "XXXXYYYYY"} }, I think something about the hashing didn't work properly because if one of them was enqueued when another one was already waiting to be executed (both using the "perform_in"), then the second was not executed, it was totally forgotten, like if it was never been added to the queue.
I downgraded to 3.0.2 and the issue is solved.
The text was updated successfully, but these errors were encountered: