Last modified: 2014-11-07 14:00:55 UTC
I noticed this today while putting together a quick and dirty tool to do a search on all wikis (using OAuth mostly because I could reuse my class). When the script came to certain wikis it wasn't getting a legitimate response back which at first I thought was just intermittent or I wasn't skipping closed wikis correctly. After some troubleshooting I realized I was getting a '500 Internal Server Error' message back instead for those wikis and after checking a couple realized it was the 2 dozen or so wikis where I didn't yet have a local account. Obviously fixing that was easy (I clicked over to those wikis, my account auto created, and I ran the search again) this doesn't seem to be how we want the process to go. For closed/fishbowl/private wikis I get a relatively nice json response saying that I don't have an account there which works well. I guess, at least, sending a message like that here would be nice. I would prefer, however, that it just auto created the account as if I was 'visiting' for the first time since I kind of am just in the form of my oauth token. My working assumption (based on no real information and just on the symptoms) is that the wiki doesn't return a 'no account found' error because it hits a snag when it finds my oAuth information in the centralWiki but doesn't find my local user account and so 'freaks out' and throws an error.
I suspect this may be the same issue as bug 62312; do the wikis with the problem also have CirrusSearch (even if not by default)? Otherwise, it would be helpful to find the backtrace for the cause of the error, which means having the timestamp and wiki for an error message and checking /a/mw-log/exception.log (or possibly /a/mw-log/fatal.log) on fluorine. Feel free to ping me on IRC if you need help with that.
(In reply to Brad Jorsch from comment #1) > I suspect this may be the same issue as bug 62312; do the wikis with the > problem also have CirrusSearch (even if not by default)? > > Otherwise, it would be helpful to find the backtrace for the cause of the > error, which means having the timestamp and wiki for an error message and > checking /a/mw-log/exception.log (or possibly /a/mw-log/fatal.log) on > fluorine. Feel free to ping me on IRC if you need help with that. Hmmm, possible though no clue, it was only the wikis listed below when I did it and they all fixed themselves after I visited them and autocreated (I checked the log each time) my current account doesn't cause the issue anymore of course but when I get a chance tonight I'll switch my dev version to try using my personal account or perhaps my old public computer account which will have a ton of unvisited sites to see how that goes. Will report back here. Wikis which failed the first time: bewikisource brwikisource elwikinews fawikinews kowikiversity liwikibooks orwiktionary sawikiquote sawikisource sahwikisource slwikiversity sqwikinews arwikimedia bdwikimedia bewikimedia cowikimedia dkwikimedia etwikimedia fiwikimedia mkwikimedia mxwikimedia nlwikimedia nowikimedia plwikimedia ruwikimedia sewikimedia trwikimedia uawikimedia
(In reply to James Alexander from comment #2) > Wikis which failed the first time: All those do happen to have CirrusSearch enabled. Conclusive proof would be a backtrace though. Looking for bewikisource, brwikisource, elwikinews, and fawikinews as examples, the only exceptions I see since 2014-03-05 are variations on this: 2014-03-06 13:52:10 mw1207 bewikisource: [d4386a1c] /w/api.php Exception from line 36 of /usr/local/apache/common-local/php-1.23wmf16/extensions/OAuth/api/MWOAuthAPI.setup.php: The authorization headers in your request are for a user that does not exist here #0 /usr/local/apache/common-local/php-1.23wmf16/extensions/OAuth/api/MWOAuthAPI.setup.php(103): MWOAuthAPISetup::makeException('mwoauth-invalid...') #1 [internal function]: MWOAuthAPISetup::onUserLoadFromSession(Object(User), NULL) #2 /usr/local/apache/common-local/php-1.23wmf16/includes/Hooks.php(206): call_user_func_array('MWOAuthAPISetup...', Array) #3 /usr/local/apache/common-local/php-1.23wmf16/includes/GlobalFunctions.php(4008): Hooks::run('UserLoadFromSes...', Array, NULL) #4 /usr/local/apache/common-local/php-1.23wmf16/includes/User.php(1007): wfRunHooks('UserLoadFromSes...', Array) #5 /usr/local/apache/common-local/php-1.23wmf16/includes/User.php(300): User->loadFromSession() #6 /usr/local/apache/common-local/php-1.23wmf16/includes/User.php(1836): User->load() #7 /usr/local/apache/common-local/php-1.23wmf16/includes/User.php(2959): User->getId() #8 /usr/local/apache/common-local/php-1.23wmf16/extensions/CirrusSearch/includes/Hooks.php(61): User->isLoggedIn() #9 /usr/local/apache/common-local/php-1.23wmf16/extensions/CirrusSearch/includes/Hooks.php(45): CirrusSearch\Hooks::initializeForUser(Object(User)) #10 [internal function]: CirrusSearch\Hooks::apiBeforeMainHook(Object(ApiMain)) #11 /usr/local/apache/common-local/php-1.23wmf16/includes/Hooks.php(206): call_user_func_array('CirrusSearch\Ho...', Array) #12 /usr/local/apache/common-local/php-1.23wmf16/includes/GlobalFunctions.php(4008): Hooks::run('ApiBeforeMain', Array, NULL) #13 /usr/local/apache/common-local/php-1.23wmf16/api.php(73): wfRunHooks('ApiBeforeMain', Array) #14 /usr/local/apache/common-local/w/api.php(3): require('/usr/local/apac...') #15 {main} If that's your errors, then this is the same as bug 62312.
Note that Gerrit change #117189 has been merged in time for 1.23wmf18. If you can somehow test this against testwiki, test2wiki, testwikidatawiki, or mediawiki.org and see if it's fixed after tomorrow's deploy, that could be helpful.
(In reply to Brad Jorsch from comment #4) > Note that Gerrit change #117189 has been merged in time for 1.23wmf18. If > you can somehow test this against testwiki, test2wiki, testwikidatawiki, or > mediawiki.org and see if it's fixed after tomorrow's deploy, that could be > helpful. James Alexander: Is this still an issue or obsolete?
