Use of i18n_patterns and a buggy 404 template trigger internal server error without a backtrace.

[Erik Stein]

– Using i18n_patterns with prefix_default_language=True,
– trying to get the frontpage URL without a language given in the URL

works in debug mode, but gives an internal server error without any backtrace in production mode.

This was caused by a buggy 404.html template, but probably buggy 404 templates should give a backtrace, too, and i18n_patterns shouldn't be concerned by this anyway.

Sample project: ​https://github.com/sha-red/bugs-django-30475

[Claude Paroz]

Probably setting up a minimal project to reproduce the issue would be great.

[Carlton Gibson]

Replying to Erik Stein:

[draft bug report, I'll try to provide more details later or on request]

Hi Erik.

Happy to look at this but, as Claude says, could you provide a sample project the reproduces the issue?

What exactly is the issue? An error in the 404 template? That i18n patterns swallows that? (Is it in fact dependent on i18n patterns?) And so on.

Thanks.

[Erik Stein]

I asked about adding a ticket for later reference before posting the issue and I would consider closing it after two days a bit unfortunate, but I don't really know your triaging policy, so please forgive me :-).

Today I've added a simple sample project. In a first check it seems that the Django test client actually deals correctly with the buggy 404 template (delivering a backtrace) making it somehow unuseful in testing the issue. I added some notes in the README instead.

[Mariusz Felisiak]

Thanks for the sample project. IMO everything works properly. In DEBUG mode Django doesn't use your custom 404.html page that's why it also doesn't propagate any errors in this page (you've already described this as a correct behavior). When DEBUG=False Django handles exception by ​handler500 view and logges them in ​django.request logger. If you want to skip this and propagate exceptions upwards when DEBUG=False you can use ​DEBUG_PROPAGATE_EXCEPTIONS setting.

[Erik Stein]

Please forgive me for reopening the ticket again!

I guess my original question and reason to open a ticket was that I'm irritated that i18n_patterns will break in production mode if you have a buggy 404 template, instead of just redirecting to the correct URL. This doesn't seem to be correct behaviour in my eyes.

[Carlton Gibson]

Hi Erik.

Sorry for your irritation. I understand these things can be frustrating.

I don't really know your triaging policy, so please forgive me :-).

See TicketClosingReasons/DontReopenTickets and The ​Triage Workflow docs.

Ultimately here I think it's up to the user to ensure their 404 template loads correctly. That's straight-forward to test. If they do introduce an error, yes we drop right through to the very bottom handle_uncaught_exception() but we know something bad has happened in that case. As Mariusz points you to, DEBUG_PROPAGATE_EXCEPTIONS reveals the issue immediately.

A custom 404 handler adding logging and/or exception handling around the get_template() call would be possible. But it's unnecessary overhead: a simple test that the 404.html template does in fact load makes this redundant.

Sorry if that's not what you want to hear.