I posted this message on -users today, but at PaulM's urging, I'm bringing it over here out of concern that it may reflect a bug in the contrib.sessions test suite.
Here's the original message from -users (some -dev only notes follow) : I am having a problem with contrib.sessions.tests.test_valid_key (line 159). It's a mixin which in the failure case is mixed with CacheDBSessionTests. The test raises: "AttributeError: 'bool' object has no attribute 'get'" The error is actually raised by session.save() on 164. Stepping inward reveals that sessions.backends.cached_db (line 18) sets data thusly: data = cache.get(self.session_key, None) QUESTION #1 (maybe more suited for django-dev?): If I step in, I find that debugging core.cache.backends.locmem.LocMemCache.get(), which is odd since the TestCase is CacheDBSessionTests. Why is it testing LocMemCache and not core.cache.backends.db.DatabaseCache? In this case, self.session_key is 1, and indeed the cache has a pickled "True" for the key 1. In fact, during the course of debugging core.cache.backends.locmem.LocMemCache.get(), we have found that in every case during which the testrunner hits this method, 1 is a key for pickled True. QUESTION #2: Why is the key 1 set to a pickled True? In this case, that True ends up being returned in contrib.sessions.backends.base.SessionBase.get() (line 64). Thus, of course an error is raised. We are unable to understand why the key 1 is set to pickled True in the locmem backend. NOW THE STRANGE PART: Iff we step in with a debugger and wait for > 3 seconds or so, the method no longer returns True and instead returns an empty dict. In this case, the test passes! We are baffled. Is this possibly an underlying race condition or hotel room scenario (http://stackoverflow.com/questions/6441218)? [END DJANGO-USERS MESSAGE] I also want to point a few additional things here on the dev list: *We have tried this on two different computers with OSX and Linux and we encounter the timing issue either way, every time. *We put a breakpoint on django.core.cache.backends.db.get() (line 38) which was never hit during the course of the sessions tests. *We were hoping to find that the test runner hit one backend if we didn't wait in state and another if we did. However, as noted in the point above, that doesn't appear to be the case (unless we're missing something about the way the backends are implemented, which is possible) *Thinking that using cached_db for the backend might result in .get() being used only in LocMem, we also put a breakpoint in backends.db.set(), thinking that both were going to be set. This breakpoint was also never hit during the course of the sessions tests. *The commit comment, by Russell Keith-Magee, seems like it is likely related: "Fixed #15026 -- Added cleanup to the invalid key session tests; when using Memcached as a cache backend, the cache-backed session backends would fail on the second run due to leftover cache artefacts. Thanks to jsdalton for the report and patch." *#15026 seems to describe a substantially different problem, but it is possible that the root cause is similar or the same: that unflushed material in the cache persists between tests. We encountered this issue at DiscSpace, which is cool enough to let freelancers work on issues in the django internals on company time if we encounter them. -- Justin Holmes Head Instructor, SlashRoot Collective SlashRoot: Coffee House and Tech Dojo 60 Main Street New Paltz, NY 12561 845.633.8330 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
