-
-
Notifications
You must be signed in to change notification settings - Fork 50
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
Unique FakeServer
breaks singleton connection in RQ tests
#204
Comments
The question is how come it creates another |
From debugging, it doesn't create another |
So it is getting a connection from another place. |
Signed-off-by: F.N. Claessen <[email protected]>
Which fakeredis version are you using? I am having a tough time replicating |
In 2.11.1 it works, broken in 2.11.2. I'll try and get a minimum reproducible setup early in the week if you can't reproduce it. |
Can you provide the full failing test? |
Based on my understanding, django_rq has logic in Here is a full working test: import fakeredis
import redis
from django.test import TestCase
from django_rq import get_worker, get_queue
redis.StrictRedis = fakeredis.FakeStrictRedis
redis.Redis = fakeredis.FakeRedis
def _noop():
pass
class DjangoRqTest(TestCase):
def test_django_rq(self):
queue_name = "default"
queue = get_queue(queue_name)
self.assertEqual(queue.count, 0)
queue.enqueue(_noop)
self.assertEqual(queue.count, 1)
get_worker(queue_name).work(burst=True)
self.assertEqual(queue.count, 0) |
* first attempt, use Flask-Classful branch. New blocker is Flask-Login and forecasting/scheduling jobs are failing now Signed-off-by: Nicolas Höning <[email protected]> * fix: from cunla/fakeredis-py#204 Signed-off-by: F.N. Claessen <[email protected]> * prevent sphinx warning Signed-off-by: F.N. Claessen <[email protected]> * black Signed-off-by: F.N. Claessen <[email protected]> * move to original rq-dashboard in .txt Signed-off-by: Nicolas Höning <[email protected]> * add comment Signed-off-by: Nicolas Höning <[email protected]> --------- Signed-off-by: Nicolas Höning <[email protected]> Signed-off-by: F.N. Claessen <[email protected]> Co-authored-by: F.N. Claessen <[email protected]>
Describe the bug
Since #142, released on 2.11.2, fake redis instances have separate state, based on a uuid. This causes issues when using as an RQ stub.
To Reproduce
Expected behavior
The above test case to pass. Which it does on version 2.11.1.
Instead, it fails on the final line, claiming that the job still exists. The method itself is also never called, so the issue is the job not running.
Desktop (please complete the following information):
Additional context
I have a fix, but I'm not sure it's quite correct. Passing dummy values for
host
andport
into the fake Redis instances results in a stable key, and thus the connection working correctly:As the class is designed to be a singleton, perhaps this is sensible. The arguments could be passed through from the singleton's constructor, but that again puts the onus of remembering the fix on the user, which isn't right.
Randomly generating the port number would also work, as at least then each "singleton" would be its own isolated server.
If that approach makes sense, I'm happy to submit a PR.
The text was updated successfully, but these errors were encountered: