If you have a custom 404 template and page not found then you got 500
error without understanding why.
Reproducible application -
https://gist.github.com/lcd1232/f242d88b1eaeaccbb6ba2e81e68644cd
One more example of a context processor that can generate the same error:
{{{
def url_info(request):
"""
Adds url info.
"""
info = resolve(request.path_info) # raised exception for 404 page
return {
"url_info": {
"app_name": info.namespace,
"url_name": info.url_name,
"full_name": f"{info.namespace}:{info.url_name}"
}
}
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/32113>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Comment (by lcd1232):
Ok. And what about adding this check for the system check framework?
--
Ticket URL: <https://code.djangoproject.com/ticket/32113#comment:2>
Comment (by Mariusz Felisiak):
Replying to [comment:2 lcd1232]:
> Ok. And what about adding this check for the system check framework?
I'm against this, we cannot add a system check for any unsupported usage.
Also I'm not sure if it's doable, because a context processor can return
`None` only under certain circumstances. You can start a discussion on
DevelopersMailingList if you don't agree.
--
Ticket URL: <https://code.djangoproject.com/ticket/32113#comment:3>
Comment (by Timothy Schilling):
The debug toolbar has hit this case a few times and it's a painful for the
maintainers to determine this is the reason the toolbar doesn't function.
Perhaps we can add more emphasis around the need to have to return a
dictionary? For example maybe adding a comment within the code example
that was introduced in v3.2 that says `# A dictionary must always be
returned`. This would be similar to how the form `clean_[field]`
[https://docs.djangoproject.com/en/3.2/ref/forms/validation/#cleaning-a
-specific-field-attribute documentation] informs developers about
returning the cleaned data.
--
Ticket URL: <https://code.djangoproject.com/ticket/32113#comment:4>