Offer a mechanism not to serve a fatal error when trying to load a non existing extension
Closed, DeclinedPublic

Description

Currently, wfLoadExtension( 'NonExistingExtension' ) break the site with a fatal error:

23:51:41 < Vito> PHP fatal error /srv/mediawiki/php-1.28.0-wmf.3/includes/GlobalFunctions.php line 115:
23:51:41 < Vito> /srv/mediawiki/php-1.28.0-wmf.3/extensions/SpamBlackList/extension.json does not exist!

To know this information could have been enough, we probably could still have served queries during the 101 seconds this incident occurred, without the extension.

Technically in the code, we could detect if $IP/extensions/<extension name>/extension.json exists before to try to include it and skip the extension load if it doesn't exist.

A missing extension condition must be known.

This need a mechanism to report loudly the missing extension.

For WMF, this means plug with existing reporting and notification systems like Logstash.

For smaller deployments, this is a good question. Some software prints visual cues. For example, Phabricator prints a small bar at the top of the screen for administrators to identify "Setup issues". But we don't have a system administrator group for such purpose. Allow to interact with existing log report and notifications systems could be valuable.

Security note

Some wikis could require an extension for security reason: for example, they could use an extension to make it or some part of it private. They are so currently protected by this fatal error.

We could offer them the same level of security, adding in the configuration an array with the list of required extension, and serve a fatal error at this moment if the critical security extension isn't loaded at the end of the registration process.

This is mostly intended for extensions exposing personal information if missing, not "very nice to have" antispam features.

Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptJun 2 2016, 12:38 PM
Krenair added a subscriber: Krenair.Jun 2 2016, 5:07 PM

Some wikis could require an extension for security reason: for example, they could use an extension to make it or some part of it private. They are so currently protected by this fatal error.

These extensions are not and should not be supported by us.

Krinkle added a subscriber: Krinkle.EditedJun 2 2016, 10:30 PM

Per @Krenair: For security reasons, we don't support such extensions. Things like "private" and "fishbowl" wikis are part of core MediaWiki configuration, not extensions.

While we may or may not want to allow edits to happen while anti-spam features are missing, there are two more categories of extensions worth considering:

  • Parser extensions: If we allow edits to be saved while a parser extension is missing, we effectively corrupt two caches: the parser cache database, and the HTTP cache (Varnish).
  • Visual extensions (relating to the skin, sidebar, or interface messages): If we allow pages to be served with 200 OK while such an extension is missing, we'll be populating Varnish with fallback pages that will be hard to purge afterwards.

Most extensions belong to one of these categories (visual, parser, anti-spam, authentication). Adding tolerance for just the few other ones wouldn't help much.

Bottom line: I don't think should allow pages to be served if an extension is missing. While that may be easy to implement and has the benefit of the site not being down, it would hurt us in the long run.

Besides, short of files randomly disappearing or changing on disk, this can only happen if they were already in that state during deployment. Which means we can catch it before deployment in a more appropriate way:

  • T136782 - [pre-commit] Unit tests for wmf-config extension loading (via Jenkins).
  • T121597 - [pre-deploy] Scap should test against local apache before syncing
  • T136883 - [on-deploy] Canary deploy process for MediaWiki

(If a file does end up randomly changing on a server's disk, an HTTP error status code is desired as that will make it get depooled automatically)

Currently, wfLoadExtension( 'NonExistingExtension' ) break the site with a fatal error:

As it should. I think we should decline this bug.

in pre extension.json days, we always used require_once over include_once for precisely the reason that failing loud and hard is ultimately better then failing quietly.

MaxSem closed this task as Declined.Jun 2 2016, 10:39 PM

I get this failure using the Purge extension. If I load with:

  • require_once( "$IP/extensions/Purge/Purge.php" );

there is no problem. But if I load with:

  • wfLoadExtension( 'Purge' );

I get the error message breaking the site. It would be really great to get a loud message, without breaking the site. Or so my users tell me.

Seb35 added a subscriber: Seb35.Oct 7 2017, 4:03 PM