Opened 4 years ago
Last modified 4 years ago
#32049 closed Bug
Middleware behaviour inconsistent between runserver and daphne — at Initial Version
Reported by: | Hugo Osvaldo Barrera | Owned by: | nobody |
---|---|---|---|
Component: | HTTP handling | Version: | 3.1 |
Severity: | Normal | Keywords: | ASGI |
Cc: | Andrew Godwin | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
All my views expect a particular middleware to have run (it detects the current tenant based on the request's host).
I'm having an issue which only occurs on production, but I could not reproduce in development mode (even with DEBUG=False
) nor via unit tests.
After just inspecting stack traces, it seems that when handler404
is run, behaviour varies between runserver and daphne.
Looking at the backtrace of my handler404
function:
- When running
django-admin runserver 0.0.0.0:8000
, all my middlewares are in my backtrace, meaning they've gotten executed and the function is called in their context. - When running
daphne myapp.asgi:application --bind 0.0.0.0 --port 8000 --http-timeout 90
, I put a tracepoint in myhandler404
, and the middleware are not in the backtrace. It seems that the view is run outside the context of these middlewares.
I haven't been able to find anything in the docs clarifying whether error handlers should expect middleware to have run successfully, but whatever the intended behaviour is, it should be consistent across the two.