Data for this panel isn't available anymore. Please reload the page and retry.

[ZhengYuan-Public]

I'm using wagtail 2.8, debug-toolbar 2.2. It was working well at the beginning, but after adding several apps into my project, I accidentally put path('__debug__/', include(debug_toolbar.urls)), below url(r'', include(wagtail_urls)), and thus I got 404 errors. I fixed the problem but the toolbar is not working anymore and I got Data for this panel isn't available anymore. Please reload the page and retry. for every panel.

Setting RESULTS_CACHE_SIZE = 100 didn't help.

[tim-schilling]

Do the requests to the toolbar (/__debug__/*) have a store id included in them?

[ZhengYuan-Public]

Do the requests to the toolbar (/__debug__/*) have a store id included in them?

[25/Mar/2020 04:48:35] "GET /static/debug_toolbar/css/print.css HTTP/1.1" 304 0 [25/Mar/2020 04:48:35] "GET /static/debug_toolbar/img/djdt_vertical.png HTTP/1.1" 304 0 [25/Mar/2020 04:49:10] "GET /static/debug_toolbar/img/indicator.png HTTP/1.1" 304 0 [25/Mar/2020 04:49:10] "GET /static/debug_toolbar/img/close.png HTTP/1.1" 304 0 [25/Mar/2020 04:49:10] "GET /__debug__/render_panel/?store_id=0d3e852087a24206aa9a7d5f2b52e957&panel_id=SettingsPanel HTTP/1.1" 200 90 [25/Mar/2020 04:49:13] "GET /__debug__/render_panel/?store_id=0d3e852087a24206aa9a7d5f2b52e957&panel_id=RequestPanel HTTP/1.1" 200 90 [25/Mar/2020 04:49:14] "GET /__debug__/render_panel/?store_id=0d3e852087a24206aa9a7d5f2b52e957&panel_id=SQLPanel HTTP/1.1" 200 90 [25/Mar/2020 04:49:15] "GET /__debug__/render_panel/?store_id=0d3e852087a24206aa9a7d5f2b52e957&panel_id=StaticFilesPanel HTTP/1.1" 200 90 [25/Mar/2020 04:49:16] "GET /__debug__/render_panel/?store_id=0d3e852087a24206aa9a7d5f2b52e957&panel_id=TemplatesPanel HTTP/1.1" 200 90 [25/Mar/2020 04:49:17] "GET /__debug__/render_panel/?store_id=0d3e852087a24206aa9a7d5f2b52e957&panel_id=CachePanel HTTP/1.1" 200 90 [25/Mar/2020 04:49:18] "GET /__debug__/render_panel/?store_id=0d3e852087a24206aa9a7d5f2b52e957&panel_id=SignalsPanel HTTP/1.1" 200 90 This is what shows in my terminal.

[ZhengYuan-Public]

Do the requests to the toolbar (/__debug__/*) have a store id included in them?

I'm not sure if my templates are problematic. I started a new project today and after using a free website templates' css and js, this problem just happened again.

The one I'm using: https://themes.3rdwavemedia.com/bootstrap-templates/startup/appkit-landing-free-bootstrap-theme-for-developers-and-startups/

[tim-schilling]

Are you running this on a server (something not local)? If so, did you restart the web server between changes?

[ZhengYuan-Public]

Are you running this on a server (something not local)? If so, did you restart the web server between changes?

I'm only running locally so far. I did try to restart the server, force reload the page and using incognito mode(chrome).

[tim-schilling]

Can you verify that the store id doesn't change from the initial response to the browser, so when the toolbar's javascript makes requests for additional content? The easiest way to do that is to open up a browser's dev tools, go to the network panel, and inspect the initial GET/POST's response, find the div with the id djDebug and look for data-store-id.

[brettdh]

@tim-schilling I have this problem as well (Django app is hosted on AWS Lambda via Serverless Framework, with static assets in S3). I can confirm that the store ID is the same in the djDebug div and the (e.g.) /__debug__/render_panel/?store_id=<id>&panel_id=SQLPanel request. The problem occurs on every panel and on every request when viewing the Django REST Framework browsable API, but it does not occur (or occur nearly as often, at least) when browsing the Django admin UI.

....which makes me wonder if the app order is the problem... but I just checked, and debug_toolbar is later in the list than both django.contrib.admin and rest_framework.

[brettdh]

Further confirmed that this problem doesn't occur with manage.py runserver.

[tim-schilling]

@brettdh A few questions:

• Is it possible to expose the values within the store? toolbar._store
• Does this problem exist before the history panel was introduced (v3.1 I think).
• You may also try increasing the RESULTS_CACHE_SIZE config setting.

[tim-schilling]

I suspect the issue is that toolbar._store is exceeding the RESULTS_CACHE_SIZE because the toolbar renders on almost every request. If the server is also processing static files and the toolbar is instrumenting them, that could get eaten up quickly.

If that does appear to be the issue, we could introduce a configuration option that would allow users to specify regular expressions or define a filtering function that would limit which requests are instrumented.

[brettdh]

@tim-schilling

• Where would I put the code to dump toolbar._store? Is that server-side or client-side?
• I'm using 3.1.1 and I don't see a history panel...
• I did try increasing RESULTS_CACHE_SIZE to 100 as in https://github.com/jazzband/django-debug-toolbar/issues/750#issuecomment-158389082, but this did not resolve the issue.

[tim-schilling]

@brettdh It's on the server side. You'd have to fork the toolbar and use that in your project. Alternatively, you can try downgrading to v2.2. Turns out the History Panel was introduced in v3. You might have the panels setting DEBUG_TOOLBAR_PANELS set to exclude it. The history panel itself is unrelated to the issue, but the other changes to support it when it was released may be the cause.

[brettdh]

IIRC this was happening before I upgraded to 3.1.1 (from 2.1), but I can try again.

[tim-schilling]

@brettdh @ZhengYuen A thing to keep in mind about the toolbar is it stores the requests in memory. If the toolbar's ajax request hits a process that does not have the toolbar's store in memory, it will not be able to fetch the details. I was able to confirm this on a heroku app by scaling down the web dyno, then scaling it back up.

Lambda in particular seems like a bad situation to try to use the debug toolbar since it's meant to be stateless.

[brettdh]

@tim-schilling again, though, it works just fine for the django admin UI; it fails in the DRF browsable API only.

I understand why you say Lambda seems like a particularly adversarial environment for the toolbar; I guess I'm more confused about why the ajax request so reliably hits the same lambda when visiting one set of URLs and so reliably fails to find the data when visiting a different set of URLs.

As a separate workaround, would it be feasible (behind a config option) to have the toolbar middleware ship all the state with the originating request, thereby eliminating the ajax requests entirely and ensuring the state is available?

[tim-schilling]

again, though, it works just fine for the django admin UI; it fails in the DRF browsable API only.

That's going to require some investigation, but if increasing the results cache doesn't alleviate the issue, I have to believe it's because the hash doesn't exist.

As a separate workaround, would it be feasible (behind a config option) to have the toolbar middleware ship all the state with the originating request, thereby eliminating the ajax requests entirely and ensuring the state is available?

I think that would be a pretty dramatic change from how things work today. It might be more feasible to allow the toolbar's store to be managed by something more persistent.

[brettdh]

Ah, so perhaps write it to the database (only when showing the toolbar) and perhaps age them out after some time. That makes sense to me. I can look into making a PR if I have some time. Either way, though, would you like a separate issue to track that feature request?

[tim-schilling]

That would be great.

[tim-schilling]

@brettdh Regarding the difference between the admin and the browseable API, is it possible that you're hitting the browseable API unauthenticated or it's not sending the cookie along that would trigger the sticky session / session affinity with the ALB?

[brettdh]

AFAICT, on both the admin UI and the browsable API, the __debug__/render_panel request is:

• sending the same sessionid cookie as the initial page load
• not sending any other relevant cookies, other than the csrftoken from some previous admin request

Further, I haven't been able to find any mention of session affinity or sticky sessions in any API Gateway documentation, so I don't know if there's any attempt to achieve it.

[mangelozzi]

@tim-schilling I have this problem as well (Django app is hosted on AWS Lambda via Serverless Framework, with static assets in S3). I can confirm that the store ID is the same in the djDebug div and the (e.g.) /__debug__/render_panel/?store_id=<id>&panel_id=SQLPanel request. The problem occurs on every panel and on every request when viewing the Django REST Framework browsable API, but it does not occur (or occur nearly as often, at least) when browsing the Django admin UI.

....which makes me wonder if the app order is the problem... but I just checked, and debug_toolbar is later in the list than both django.contrib.admin and rest_framework.

My pages use a lot of static files, is the toolbar being rendered everytime a static file is requested? Maybe thats why the data is no longer available (even with 'RESULTS_CACHE_SIZE': 100).