jazzband
Request History does not work with Channels
Hello,
I remember in the past at one point I got the request history panel working, but now if I need to use it, it won't work.
On the front end I have enabled: History, Versions, Time, and SQL panels.
Now if I click on the History tab, then there no rows.
And if i click on the Refresh button, i get 400 error:
I have no idea what I am doing wrong or how to troubleshoot that problem. Any suggestions, what should I try next?
Dependencies: Django==3.1.3 django_debug_toolbar==3.1.1
Edited:
Environment: Docker python:3.9.0-slim
Configuration:
settings.base.py
DJANGO_APPS = [
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles'
]
LOCAL_APPS = [
. . .
]
THIRD_PARTY_APPS = [
'channels',
'rest_framework',
'axes'
]
INSTALLED_APPS = DJANGO_APPS + LOCAL_APPS + THIRD_PARTY_APPS
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
'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',
'axes.middleware.AxesMiddleware'
]
settings.development.py
import socket
from .base import *
DEBUG = True
AXES_ENABLED = False
# django-debug-toolbar
MIDDLEWARE += ["debug_toolbar.middleware.DebugToolbarMiddleware"]
hostname, _, ips = socket.gethostbyname_ex(socket.gethostname())
INTERNAL_IPS = [ip[:-1] + '1' for ip in ips] + ['127.0.0.1', '10.0.2.2']
INSTALLED_APPS += ["debug_toolbar"]
. . .
Can you share your app settings?
Updated the issue with some configuration. Is there anything specific you would like to know?
I'm using Python 3.9 as well, I don't think Python is the problem here. I have no idea what the problem might be :/
Do you have applications installed in your browser that can interfere with the execution of javascript on the page? There is also a possibility that the page may contain your scripts from the template that can break the panel. I do not see similar problems with the given configuration.
Do you have applications installed in your browser that can interfere with the execution of javascript on the page? There is also a possibility that the page may contain your scripts from the template that can break the panel. I do not see similar problems with the given configuration.
I have tried with different browsers and even on the empty HTML page that occurs.
That is in Fetch init:
Looking at the history refresh view, I see that form is not validating, that's why I get 400 error, but why it is not validating...
I came across just such a message. But the problems with the refresh could not be repeated.
Okei, I found the source of the problem.
I have installed the channels==3.0.2 package too and if I have channels configured, then runserver command automatically starts the ASGI server and I think that is where the problem lays...
Without channels in the INSTALLED_APPS, everything works again.
Keep it open for now until someone can investigate the issue more fully. I changed the title to be more explicit about the actual cause of this problem to help others identify problems. If you want to dig into why channels and the toolbar aren't working well you're more than welcome to.
@KStenK You can get the request history panel to work with channels by setting RENDER_PANELS to False. The names of the functions and settings seems to be off here. The problem is that channels is setting request.META["wsgi.multiprocess"] to True. By configuring RENDER_PANELS to False, you'll bypass that.
@KStenK There's definitely a chance that the toolbar will not work with channels given it runs with multiple processes and the toolbar's data is stored in memory.
@KStenK There's definitely a chance that the toolbar will not work with channels given it runs with multiple processes and the toolbar's data is stored in memory.
Just an aside: I was getting this error without channels with a nginx <-> uwsgi <-> django deployment. Reducing the number of processes to 1 in the uwsgi config solved it. Thanks for pointing this out, maybe it should be in the getting started docs somewhere?
