Logstash says:
[9021d8ae] PHP Fatal Error: Class undefined: MediaWikiServices MediaWiki or an installed extension requires this class but it is not embedded directly in MediaWiki's git repository and must be installed separately by the end user.
/srv/mediawiki/php-master/extensions/Thanks/includes/ThanksHooks.php
Line 104
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | demon | T183959 1.31.0-wmf.20 deployment blockers | ||
| Resolved | Addshore | T186618 PHP Fatal Error: Class undefined: MediaWikiServices - ThanksHooks |
Seems to be impacting quite a few key pages on mobile and desktop - diffs and history not viewable.
Change 408556 had a related patch set uploaded (by Addshore; owner: Addshore):
[mediawiki/extensions/Thanks@master] Import MediaWikiServices in ThanksHooks
Change 408556 merged by jenkins-bot:
[mediawiki/extensions/Thanks@master] Import MediaWikiServices in ThanksHooks
This was reported three times before it reached production:
How should issues like this (unexplained 500/503) be reported so that they are investigated?
How should issues like this (unexplained 500/503) be reported so that they are investigated?
I guess with Beta-Cluster-reproducible, which should probably be checked at branch / train deploy time for group0 for new / high prio stuff.
I also made this ticket a blocker of the train, as stuff was evidently quite broken.
Good question. I suspect these all should have been tagged unbreak now on creation. That would have helped as it would have got a wider audience attention.
T186186: History broken on beta when logged in was filed last Wednesday, with Beta-Cluster-reproducible. Should I have added it as a train blocker then? In hindsight probably would have been a good idea, but that does not bring the ticket to the relevant team's attention. Should there be some process/expectation to triage beta cluster bugs for a team's repos more quickly?
An error that will only reach production in a week is not really drop-everything-right-now-and-start-working-on-it priority though (which is how we typically use unbreak now).
An error that will only reach production in a week is not really drop-everything-right-now-and-start-working-on-it priority though (which is how we typically use unbreak now).
I'd argue it is for exactly the reason this happened but I get your point. The good things about unbreak nows is we can also downgrade them if we realise they are not a train blocker.
Should there be some process/expectation to triage beta cluster bugs for a team's repos more quickly?
Maybe, but I guess that would require help from RelEng where the problematic extension is not known. Eg. had Thanks been identified as the problem, it would have probably been routed to the right team quicker.
The report was tagged with Thanks (the error message made that pretty obvious) so it was the routing part that failed.