-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Add error view for error handling and error view testing #11263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I was having trouble testing error views and templates locally and found at some point we added a `/500` for testing the 500 error page. I expanded on this to create a view that could emit any error status code and relevant template. Afterwards, it seemed like we had a few redundant views doing similar things, so I expanded the dashboard error handlers to all use the same view as well. Changes here are: - When using the new dashboard, dashboard error templates are in the `/errors/dashboard/` template path. There will be a duplicate set of templates for Proxito errors and documentation errors, in `/errors/proxito/` eventually. - This swaps out the URL `handler500`, and defines the missing handlers in the URL module. Mostly, this loads these error templates from a more structured path instead of top level `/404.html` templates. - Adds a debug view/URL for testing arbitrary error views/templates in debug mode. This does not touch proxito error pages yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great!
This is just the dashboard response view for spam projects.
The test failure is due to the default handler giving up on loading a missing template: https://github.com/django/django/blob/main/django/views/defaults.py#L139-L150 I'll see about adding this or just add a 403 template, it probably doesn't matter as we're already not giving a templated response in these views. |
The 401 template has copy closer to 403 already, and I don't believe we are emitting a templated 403 response anywhere either.
I did indeed just symlink the 401 to 403 template for now. I'm guessing if anyone is replicating the test case responses in real life, they are just getting the default, empty, Django 403 reponse. The 401 template wasn't entirely a great fit, but it's good enough because of all of this. Same on https://github.com/readthedocs/readthedocs-corporate/pull/1767 |
Docs failures are unrelated, I'll merge this now. |
This is why the fancy 404 pages weren't working on production yet? 😄 |
I was having trouble testing error views and templates locally and found
at some point we added a
/500
for testing the 500 error page. Iexpanded on this to create a view that could emit any error status code
and relevant template. Afterwards, it seemed like we had a few redundant
views doing similar things, so I expanded the dashboard error handlers
to all use the same view as well.
Changes here are:
/errors/dashboard/
template path. There will be a duplicate set oftemplates for Proxito errors and documentation errors, in
/errors/proxito/
eventually.handler500
, and defines the missing handlersin the URL module. Mostly, this loads these error templates from a
more structured path instead of top level
/404.html
templates.debug mode.
This does not touch proxito error pages yet.