Custom 500 page is failing in production

[stevejalim]

Description

Noticed this in Sentry the other day and it's back again (eg https://mozilla.sentry.io/issues/5477071780/)

Could not parse the remainder: '('error-page-error-page-internal-server-error')' from 'ftl('error-page-error-page-internal-server-error')'

It's an odd one, and seems to be relatively recent - most likely coinciding with the folding in of Wagtail (even though the admin side is still hidden away and unreachable, Wagtail's main page-rendering view is still the last one to be called in our urlconf)

There are two things here:

1) why are we getting a 500 on that path /hr/firefox/channel/desktop/ ? 2) why is the 500 page blowing up?

If this is basically Django saying "I don't know what this ftl tag is", that would suggest that our 500 (and presumably 404?) template are being rendered as Django templates not Jinja templates.

Will investigate shortly - @stevejalim

---

Success Criteria

• [ ] Have reproduced the issue locally
• [ ] Have solved the issue locally

[stevejalim]

So https://www-dev.allizom.org/hr/firefox/channel/desktop/ is not 500ing for me, so it's not a consistent fail, and https://www.mozilla.org/hr/firefox/channel/desktop/ is fine - so this could have been a high-load glitch or similar

Still leaves the question about the exploding HTTP 500 page tho

[stevejalim]

Locally, if i put a deliberate error in a test view (raising an Exception in mozorg.views.HomeView.get_template_names and ensuring settings.DEBUG is False) I can't replicate this issue. All locales tried (en-US, en-GB and, crucially, the ~hu~ hr locale) all show the custom, localised 500 template - e.g.:

EDIT: hr locale, not hu

[janbrasna]

@stevejalim If that makes any difference hu != hr so you might wanna triple check even that locally, to be 100% sure it's not really something Croatian-related.

[stevejalim]

Thanks @janbrasna - I appreciate the call-out there. My bad for moving too fast.

As it happens, hr and hu both work fine - i've updated my comment above. Thanks, dude!

[alexgibson]

The source of this traffic in Sentry looks suspicious to me. Perhaps someone scanning the dev server.

However the source of the error in Django seems to be here: https://github.com/django/django/blob/main/django/template/base.py#L705-L709

[alexgibson]

All the errors I see in Sentry seem to be from this function blowing up: https://github.com/mozilla/bedrock/blob/main/lib/l10n_utils/__init__.py#L23-L36

Afaik, this template_source_url is not actually used anywhere (it used to be to render a link to the template in GitHub from the site footer).

It also looks like the long stack traces are the 500 page error-ing on itself recursively.