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.