Last modified: 2014-02-04 02:49:46 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T40127, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 38127 - ResourceLoader: Make file-not-found failures easier to detect
ResourceLoader: Make file-not-found failures easier to detect
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.17.x
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-02 22:31 UTC by Krinkle
Modified: 2014-02-04 02:49 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Krinkle 2012-07-02 22:31:20 UTC
If one creates a module with files that don't exist (or better yet, remove files in a module and forget to update the definition) - and the module can even be loaded on all pages. Then nothing will be visible.

* No console logs (whether with or without debug enabled)
* No PHP exceptions

The only thing shown:
* look up the load.php request in the browser debugger and see the exception in a javascript comment about file not found. And here it also shows the call to mw.loader.state({'foo':'missing'});

But since it is loaded with load() and not using() there is no other visible failure.

I'm note sure if throwing an exception on page views is wise, but it should at least make unit tests fail. One way or another.
Comment 1 Krinkle 2012-07-02 22:34:11 UTC
This would prevent Ib40d09071ba315da6b17fc94cca5746ed4c26342
Comment 2 Brion Vibber 2012-07-03 17:52:08 UTC
At least a console.log() (if console exists) would be nice.

We don't necessarily want to break processing by throwing an exception, so that one plugin being missing doesn't explode the site...
Comment 3 Krinkle 2012-07-03 17:57:09 UTC
Yeah, as far as the production flow goes, this isn't an issue. The server properly response with mw.loader.state({'foo':'missing'}) pointing the state machine in the right direction and handling of dependencies all go as expected. Nothing is visibly failing or stuck half-way initialization.

I find interesting that the server responds with "missing" instead of "error". This suggests that perhaps the module wasn't allowed to be registered in the first place (i.e. the exception was thrown in ResourceLoader::__construct or ::register?).

If that's the case, we could log from mw.loader.state instead.
Comment 4 Krinkle 2013-08-12 06:02:21 UTC
The discoverability of these errors has been improved a lot by:


resourceloader: Write to debug log for all fatal errors
Bug: 44018
Change-Id: I684f6492f839a6c6adb07b0640e88cfea21fcf60

resourceloader: Consistently use 'resourceloader' log group
Bug: 44018
Change-Id: I9907b374fa868c04ff2ce40964238936b9084a4a
Comment 5 Krinkle 2014-02-04 02:49:46 UTC
(In reply to comment #4)
> The discoverability of these errors has been improved a lot by:
> 
> 
> resourceloader: Write to debug log for all fatal errors
> Bug: 44018
> Change-Id: I684f6492f839a6c6adb07b0640e88cfea21fcf60
> 
> resourceloader: Consistently use 'resourceloader' log group
> Bug: 44018
> Change-Id: I9907b374fa868c04ff2ce40964238936b9084a4a

Good enough for me.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links