Check to see if process_request of SilkyMiddleware has been called, and issue warnings on middleware placement if not

[sabine]

When I use django.middleware.locale.LocaleMiddleware together with silk, I'm able to trigger the following error by going to /admin/ and /example_app/ (you need to go to both of them to trigger the error):

AttributeError: 'thread._local' object has no attribute 'temp_identifier'

Trace and settings:
https://gist.github.com/grumpi/f0867ac818b6c193fa62

Modified example app to trigger this behavior:
https://github.com/grumpi/silk/tree/localemiddleware-bug

I tested this on Django 1.7.1 and Django 1.6.5. It looks like, somehow self.local.temp_identifier isn't set up properly. Might or might not be related to the duplicate key issue.

[mtford90]

Hey,

So I don't think this is an issue with LocaleMiddleware in particular. The Silk middleware is placement sensitive. If process_request returns from a preceding middleware then the silk middleware will never get the chance to execute its own process_request which means that some initial setup is missed. In other words, process_response of the Silk middleware is dependent on process_request being executed.

This should def be clearer anyway, could probably build something in that checks to see if process_request was called when any of silks components are executed, and issue a warning if not. Will leave this issue open to track that.

[sabine]

Oh okay, my bad. When I place it as first middleware on that example, it seems to work nicely.

Yet, on my own project, I can't place SilkyMiddleware before Localemiddleware - when I do, things break in such a way that I can only access the main locale (all the URLs for the other locales give me 404s). I can still use it on all the URLs that are still served, but I'm wondering why what I see happens. There might just be something wrong with my configuration. That's why I'm trying to find a small example to understand what's going on.

[mtford90]

That's weird, I wouldn't expect the silk middleware to interfere with any others if placed first. It doesn't return anything from process_request so the request should carry on moving through the middleware stack...

Maybe it's something to do with the fact that process_request is decorated with silk_meta_profiler? That shouldn't be returning anything either but try removing that from the middleware and see what happens. (totally clutching at straws here tho)

[sabine]

After adding

LANGUAGES = (
('en', 'English'),
('de', 'Deutsch'),
)
to django_silky/settings.py (modified example in https://github.com/grumpi/silk/tree/localemiddleware-bug), I have the following situation:

[12/Nov/2014 17:39:01] "GET /de/example_app/ HTTP/1.1" 404 2425

Page not found (404)
Request Method: GET
Request URL: http://127.0.0.1:8000/de/example_app/

Using the URLconf defined in django_silky.urls, Django tried these URL patterns, in this order:

^silk/
^en/
^login/$ [name='login']
^static\/(?P<path>.*)$
^media\/(?P<path>.*)$

The current URL, de/example_app/, didn't match any of these.

Uncommenting SilkyMiddleware, the page is served normally.

Uncommenting @silk_meta_profiler in middleware.py doesn't seem to make any difference.

That seems to be the same issue I have in my project with LocaleMiddleware. I totally agree that it's pretty mysterious. At least I've now nailed it down to a pretty small example.

[mtford90]

Ok weird, others in the past have had issues with Silk and the url conf, in fact someone made a pull request making some changes which was supposed to have fixed these kind of issues (assuming Silk is indeed the problem here). I've had a ton of issues myself getting the urls to work properly.

Unfortunately I have zero experience with locale. I'll take a look at the example you've put together at some point tomorrow

[mtford90]

Done.