Weird "Silk middleware has not been installed correctly" error

[kqr]

Hello, I'm encountering a weird problem with Silk.

First off: the silk middleware is at the top of my middleware stack (I've tried other positions as well) so nothing should be able to stop it from running. What happens though is that the first request issued when the server has started passes through fine. The second request gets stuck in the Silk middleware.

In line 94 of middleware.py:process_request, it throws a RuntimeError exception at

    request_model = RequestModelFactory(request).construct_request_model()

I dug a little deeper and it appears as though what fails is

    request_model = models.Request.objects.create(
            path=path,
            encoded_headers=self.encoded_headers(),
            method=self.request.method,
            query_params=query_params,
            view_name=view_name,
            body=body)

at lines 159–165 in model_factory.py:construct_request_model. I had this open in PDB, so I tried manually issuing the call to models.Request.objects.create, and got the same result. It appears as though it happens at some point when the Request model is save()d, but I haven't been able to figure out more accurately what happens there.

This is the error that is eventually thrown by save()

*** RuntimeError: Silk middleware has not been installed correctly. Ordering must ensure that Silk middleware can execute process_request and process_response. If an earlier middleware returns from either of these methods, Silk will not have the chance to inspect the request/response objects.

And it's worth noting that this does not happen the first request that is issued to the server, only all the ones after that!

I'm not sure how much of this is my fault, nor what I'm doing wrong if anything, but I figured it might be something you'd like to know about if it's an issue in Silk. This is with Django 1.5.9.

I'm don't know if this matters at all, but I noticed that configure() which creates the thread-local storage is called after the RequestModel is created. From what I can tell, the RuntimeError is issued when the thread-local storage is not yet created. On the other hand, configure must be called after the requestmodel is created because it takes it as a parameter.

[mtford90]

Hey buddy, huge apologies for late reply. I haven't actually used Silk with 1.5 for ages (I think it's deprecated now?) but I wouldn't expect it to break like this. Is this happening with manage.py runserver? If not, what's your setup?

[kqr]

1.5 is indeed deprecated, I use it for a non-public thing where there just hasn't been time to upgrade. Yes, through manage.py runserver.

[imaia]

I get this error too using django-extensions (ForeignKeyAutocompleteAdmin) with django-silk

[sadan]

Any solution of this issue? I am also facing this issue while working with django-channels (sockets).

[dunkelstern]

It seems running runserver --nothreading fixes the problem, but that can't be the solution

[cyberbudy]

Is there any progress on it? I have this problem with django-channels

[scottkidder]

Still experiencing this as well with channels.

[physicalattraction]

I am not using django-channels, and experience this problem in Django 2.1. This is my MIDDLEWARE:

['django.middleware.gzip.GZipMiddleware',
 'silk.middleware.SilkyMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.common.CommonMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'django.middleware.clickjacking.XFrameOptionsMiddleware',
 'django.middleware.security.SecurityMiddleware']

The only middleware before the Silk middleware is from Gzip, as it should be according to this issue.

[sadan]

Does someone know at which piece of code is causing this issue? let's try fix this..

[deepuonthemove]

Hi guy, Any update on the above issue, We are also facing it with a similar middleware configuration

MIDDLEWARE_CLASSES = (
'django.middleware.gzip.GZipMiddleware',
'silk.middleware.SilkyMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'django.middleware.security.SecurityMiddleware')

[dondrzzy]

Came across the same issue. We had oauth2_provider.middleware.OAuth2TokenMiddleware' middleware above silkyMiddleware and for every invalid oauth token that was passed, that error would get thrown. We moved it to the bottom and that fixed the issue.