History panel remains empty

[ppfeufer]

For some reason I can't figure out, my history panel is always empty.

All other panels work just fine.

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    "debug_toolbar.middleware.DebugToolbarMiddleware",
    "django.middleware.locale.LocaleMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.middleware.csrf.CsrfViewMiddleware",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    "django.contrib.messages.middleware.MessageMiddleware",
    "django.middleware.clickjacking.XFrameOptionsMiddleware",
]

[tim-schilling]

Hi @ppfeufer! Are you running this locally? What does the rest of your toolbar setup look like? What does your urls.py that includes the toolbar's url look like?

[ppfeufer]

Hey there,

urls.py:

import debug_toolbar

from django.conf import settings
from django.conf.urls import url
from django.urls import include, path

from allianceauth import urls

urlpatterns = [
    # debug toolbar
    path("__debug__/", include(debug_toolbar.urls)),
    # alliance auth urls
    url(r"", include(urls)),
]

base.py;

INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    "django.contrib.humanize",
    "django_celery_beat",
    "bootstrapform",
    "sortedm2m",
    "esi",
    "allianceauth",
    "allianceauth.authentication",
    "allianceauth.services",
    "allianceauth.eveonline",
    "allianceauth.groupmanagement",
    "allianceauth.notifications",
    "allianceauth.thirdparty.navhelper",
]

in local.py where debig_toolbar is added:

INTERNAL_IPS = ["127.0.0.1"]

INSTALLED_APPS += [
    "debug_toolbar",
]

[ppfeufer]

And yes, it is locally

Need the apache conf as well?

[tim-schilling]

Are you using Django channels?

[ppfeufer]

I actually had to google what that is, so I would say no.

[sjdemartini]

I have this same problem, and I figured out a way to reproduce it vs not. I'm not using Django Channels either, but I noticed that the problem only occurs if I use uvicorn and asgi locally, rather than using runserver with the wsgi appilcation. Changing the order of middleware has no effect for me.

• Using uvicorn config.asgi:application --host 0.0.0.0 --reload locally (with config/asgi.py that includes: from django.core.asgi import get_asgi_application and django_application = get_asgi_application()), the History panel always ends up blank (identical to the screenshot in the original post).

• Using python manage.py runserver (with a wsgi file that includes: from django.core.wsgi import get_wsgi_application and application = get_wsgi_application()), the History panel works properly.

As a workaround, I have been installing and using the separate RequestHistoryPanel for now (https://github.com/djsutho/django-debug-toolbar-request-history), which works just fine with asgi and uvicorn, but I'd love to drop it and take advantage of the built-in History panel if this were fixed.

Thanks in advance!

[tim-schilling]

I perhaps should have asked if you were using asgi @ppfeufer. Can you both try setting RENDER_PANELS to false?

[sjdemartini]

Thanks @tim-schilling! Setting RENDER_PANELS to False gets the History Panel to render!

However, there's a new issue. I'm now seeing that after initial load, if more AJAX requests are made, I can only get them to show up in the history list by hitting the DDT Refresh button (seemingly expected). More importantly, if I then try to Switch to one of them, I get a 400 response from /__debug__/history_sidebar/ with the content Invalid signature. (Seemingly related to #1413.)

[tim-schilling]

Alright thank you. I wasn't sure if that would entirely work. I had started on getting the toolbar to work with ASGI in the past, but didn't complete it.

[ppfeufer]

Setting RENDER_PANEL to False does indeed result in a rendered History panel.

But I get an Internal Server Error when clicking on "switch" on an Ajax call

[23/Jun/2021 19:21:31] ERROR [django.request:224] Internal Server Error: /__debug__/history_sidebar/
Traceback (most recent call last):
  File "/mnt/sda1/public_html/allianceauth/venv-3.9/lib/python3.9/site-packages/django/core/handlers/exception.py", line 47, in inner
    response = get_response(request)
  File "/mnt/sda1/public_html/allianceauth/venv-3.9/lib/python3.9/site-packages/django/core/handlers/base.py", line 181, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/mnt/sda1/public_html/allianceauth/django-debug-toolbar/debug_toolbar/decorators.py", line 15, in inner
    return view(request, *args, **kwargs)
  File "/mnt/sda1/public_html/allianceauth/django-debug-toolbar/debug_toolbar/decorators.py", line 30, in inner
    return view(
  File "/mnt/sda1/public_html/allianceauth/django-debug-toolbar/debug_toolbar/panels/history/views.py", line 19, in history_sidebar
    for panel in toolbar.panels:
AttributeError: 'NoneType' object has no attribute 'panels'

[sjdemartini]

On the latest version of DjDT, I'm seeing that "RENDER_PANELS": False now allows the History panel to function without errors on an ASGI server, such that I can see AJAX requests, click the Switch button to switch to them, and thereafter view their SQL queries etc. (The switching was broken before, as mentioned above #1476 (comment).) For what it's worth, I still do have to click Refresh at the top of the History panel every time new AJAX requests are made, which seemingly is not expected per the 3.3.0 changelog mentioning "Automatically update History panel on AJAX requests from client".

So I guess this may be mostly but not fully resolved. (And it seems to require that RENDER_PANELS is False, which is perhaps not ideal, since it will only work on single-process servers.) Thanks for the continued updates to DjDT; glad to be able to take advantage of the newer features now, given whichever improvements allowed this to start functioning on ASGI!

[tim-schilling]

@sjdemartini what are you using to make those AJAX requests? Is it XHR, fetch or something else?

[sjdemartini]

@tim-schilling I was using fetch for the above AJAX requests.

[tim-schilling]

Perfect, then this can be closed as a part of #1650.