In general, browsers do not execute JavaScript if the response to a script request does not have a javascript content-type, such as HTTP 500 error messages. I've confirmed this in Firefox, Safari and Chrome locally.

There would be a SyntaxError reported in the console if the browser even considered parsing or executing these responses.

I imagine this kind of SyntaxError would be more commonly reported if browsers did this anytime an asset request failed in an HTTP 500. While this is fortunately not common in production, we have had a number of isolated incidents in recent years and given the instrumentation is unsampled and on all Wikipedias, this would statitically have to have been logged by now.

In any event, SyntaxErrors due to HTML responses under error scenarios are not something I think requires any action or further improvement.

• Each script runs as its own task with its own call stack. This means it is not affecting other features or web requests.
• The reporting happens regardless of whether the error is already handled by the UI.
• Our UI and internal loading logic is able to, and generally does, handle this when appropiate. E.g. propagate error state, or acknowledge and display an error, or go into a recovery/fallback.
• If there is an outage or intermittent issue preventing the script from being delived, then that state is essentially final. Unless the task is about the cause of the HTTP 500 response itself, there isn't anything we need to do about the cascading reports of the (invisible, and generally gracefully degrading) script failures from such error reponse.