Page MenuHomePhabricator

API fallback for Javascript error logging (if no Sentry etc available)
Open, LowPublic


For small wikis which do not want to install Sentry or another error logging solution, provide simple error logging via the standard API.

Event Timeline

Tgr raised the priority of this task from to Needs Triage.
Tgr updated the task description. (Show Details)
Tgr added projects: JavaScript, MediaWiki-API, Sentry.
Tgr added a subscriber: Tgr.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Aklapper renamed this task from API fallback for Javascript error logging to API fallback for Javascript error logging (if no Sentry etc available).Feb 23 2015, 12:05 PM
Aklapper triaged this task as Low priority.
Aklapper set Security to None.

I'm not terribly fond of the idea of strange, special-purpose internal endpoints in the public API.

What exactly is supposed to be logged here, and why can't a small site that wants this logging information install "Sentry or another error logging solution"?

This would log some serialization of Javascript errors, probably the value of Error.prototype.stack (need to check cross-browser support). One frequently voiced request in the SOA discussions was (as I understood it) was that core MediaWiki features should have a fallback that works on shared hosts and other environments where the wiki owner does not have root access. Sentry is a Django app with various package dependencies, backends and worker queues, and the free plan of the SaaS version is rather limited, so per that rule there should be a fallback.

It does not have to be special-purpose though, could be a generic log API (as in MWLogger, not LogPage).

OTOH, there's a difference between essential services and something like this that the site will continue to work perfectly well without.

Keep in mind the possibility of a malicious user using this facility to try to flood logs, BTW.

At the time of creating this task it was assumed that the server side implementation of error logging would be based on Sentry. We have eventually decided on a different implementation, so de-tagging.