[00:12:13] * For really cool vim folding this needs to be at the end: [00:12:13] * vim: foldmarker=@{,@} foldmethod=marker [00:12:13] */ [00:12:19] Why do we only have this randomly in some files? [03:30:42] Reedy: it depends who originally wrote the files :p [13:03:01] AaronSchulz: Assuming clicking through stuff in that xhgui trace linked there is accurate, all 4 times getSlotParserOutputUncached is being called from DerivedPageDataUpdater::getCanonicalParserOutput at which point I say to ask Daniel. [13:28:51] anomie: db updates on beta have gone really slow... [13:28:56] 'User name "Lhagiang" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.' [13:29:16] Should it be ok just running that script over all wikis without any specific parameters? [13:30:00] Reedy: Should be, yes. Although I have to wonder why it would be needed. [13:30:10] Imported pages? [13:30:39] https://phabricator.wikimedia.org/P7671 [13:30:43] There's literally loads of htem [13:30:51] Imported pages should have either used an interwiki username or attached it to an already-existing account for the user. Unless there's some non-standard import script in use that was never updated. [13:31:09] Imports before the scripts were updated? [13:31:47] The code in core was updated at the same time as update.php, I believe. [13:34:55] Hmm [13:34:56] $this->addOption( 'prefix', 'Interwiki prefix to apply to the usernames', true, true, 'p' ); [13:35:03] Guess I need to set that [13:36:29] aawiki [13:36:29] ----------------------------------------------------------------- [13:36:29] aawiki: ...Update 'CleanupUsersWithNoId' already logged as completed. [13:36:32] Just simplewiki then? [13:36:55] reedy@deployment-deploy01:~$ mwscript cleanupUsersWithNoId.php --wiki=simplewiki --assign --prefix=noid | tee ~/noid.log [13:36:55] ...Update 'CleanupUsersWithNoId' already logged as completed. [13:36:57] wat [13:37:01] Reedy: This is on Beta Cluster, right? I can't find the rows in your paste. [13:37:08] Yeah [13:37:51] e.g. using the username from line 44, it returns three rows all of which have a non-zero rev_user. [13:39:10] Ah ha. rev_user is 5258 for those rows, but there's no corresponding row in the user table. WTF? [13:39:15] Reedy: ^ [13:39:44] Completed actor creation, added 0 new actor(s) [13:39:44] Beginning migration of revision.rev_user and revision.rev_user_text to revision_actor_temp.revactor_actor [13:40:50] There are apparently 26783 such id+name combinations in the revision table on Beta simplewiki. [13:42:17] :/ [13:42:35] I'm guessing as it got to simple pretty quickly, other wikis before don't have the same issue (dunno about wikis after) [13:43:27] Timestamps on those revisions are from 20020225154311 to 20120104023906. I wonder, did someone just copy the revision table from production simplewiki over to Beta in 2012 without copying the user table? [13:44:00] that wouldn't surprise me, as simplewiki was a full copy of the prod wiki [13:44:48] Hmmm [13:44:53] Yeah, it sounds vaguely familiar [13:47:12] If that's the case, probably the best fix is to manually update the database to set rev_user = 0 and add an "imported>" prefix to rev_user_text for such revisions. Probably also revisions where there is a user table row but rev_user_text != user_name. [13:48:16] And then the same for archive, logging, image, oldimage, filearchive, ipblocks (ipb_by/ipb_by_text). And in theory recentchanges, although any problems there should have long since expired. [13:51:33] bleugh, fun times [13:53:18] https://phabricator.wikimedia.org/T206859 filed in the first instance [13:53:59] Reedy: Hmm. And then we'll want to truncate revision_actor_temp and zero out the *_actor fields in those other tables, then re-run maintenance/migrateActors.php. [13:54:18] Can't help feel it might be easier just to truncate everything [13:55:19] Wouldn't that break how simplewiki is supposed to be a full import for some sort of testing? [13:56:50] https://simple.wikipedia.beta.wmflabs.org/wiki/Special:RecentChanges?hidebots=1&hidecategorization=1&hideWikibase=1&limit=50&days=7&urlversion=2 [13:57:06] Does anyone else feel like ZoomSquirrel99 is actually spamming? [13:57:12] There's a mix of good and bad revisions [13:59:20] Those are the only changes in the last 30 days, lol [14:01:15] Do we want to make a list of SQL commands to run on the wiki on the phab task? [14:01:46] Reedy: I can write a draft, sure. [14:01:53] Thanks [14:02:02] greg-g: thcipriani ^^ fyi [14:23:54] Reedy: T206859#4661509 [14:23:55] T206859: beta simplewiki in a bad state due to production tables being imported - https://phabricator.wikimedia.org/T206859 [14:34:22] Thanks [14:34:32] I'm intrigued to see how well https://git-scm.com/book/en/v2/Git-Tools-Rerere might work for some of the simple conflicts we get [15:15:01] sloow update is slow [16:28:17] still going [16:54:34] anyone know of a maint script to reset the page_latest for a page using the max rev id for that page from the revision table? [16:54:38] or do I need to write one? [16:57:28] wait, maybe I don't need that [16:57:41] attachLatest.php [17:48:13] https://imgur.com/a/EHWMXNm [18:00:10] Reedy: awesome [18:00:39] Reedy: is that normally a quick script? :P [18:01:26] looking at it, it does no batching at all? >.> [18:08:46] addshore: You asked if there was a script [18:08:55] Not that if it was performant ;) [18:10:23] No slave waiting either [18:30:06] addshore: Is the Wikibase 7.1 failure fixed now? Sorry, I probably should've reverted the ci change after noticing that it wasn't fixed yet [18:36:20] legoktm: yes it should be [18:36:26] i havn't verified that it is fixed yet [18:36:44] since it merged I think it is :p [18:36:54] Reedy: yeh, I hacked together a little custom thing and added a slave wait and it just finished [18:59:54] legoktm: so are we voteizing 7.1 today? [19:00:03] MaxSem: I did it last night :) [19:00:10] \m/ [19:00:26] You're awesome legoktm [19:00:44] ^.^ next is 7.2! [19:02:04] do we have an experimental job? [19:05:06] not yet [19:06:48] I think we need to do a bit of performance improvements on quibble stuff before we roll out another job [19:08:13] Or we can just kill HHVM ;) [19:15:47] And 7.3. ;-) [20:33:22] anomie: Running update.php on beta yields a lot of these messages: [20:33:37] > User name "Word" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation. [20:33:55] Krinkle: T206859 [20:33:55] T206859: beta simplewiki in a bad state due to production tables being imported - https://phabricator.wikimedia.org/T206859 [20:35:01] anomie: thx, I'll skip that one for now. For what it's worth, it's not where the Jenkins job was stuck. It was stuck on a Flow update for ruwiki-beta [20:53:19] https://phabricator.wikimedia.org/T206832#4662450 [20:53:26] Apparently 13 releases isn't enough time to repalce something [21:13:31] I'm trying to understand the output of a phpunit build for an extension I'm working on. For this patch, https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/464432/17, I see `OK (4 tests, 6 assertions)` at https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-hhvm-docker/20545/consoleText [21:14:20] But when I run tests locally in Vagrant, I get `OK (35 tests, 48 assertions)` with this patch and `OK (18 tests, 18 assertions)` on master [21:15:10] In Vagrant, I'm running `php tests/phpunit/phpunit.php --wiki wiki --testsuite extensions extensions/WikimediaEvents/tests/phpunit` which is different than what I see in Jenkins (`php tests/phpunit/phpunit.php --debug-tests --testsuite extensions --group Database --exclude-group Broken,ParserFuzz,Stub`) [21:17:43] kostajh: there are two phpunit runs, it first runs databaseless tests, then qunit/browser, then database requiring tests [21:17:50] the first run shows OK (1566 tests, 23356 assertions) [21:18:29] ctrl+f for "PHPUnit 4.8.36" in the log [21:36:14] legoktm: oh, that makes sense. Thank you! [21:41:36] Reedy: Feel like declaring https://phabricator.wikimedia.org/T178844 done by dint of "To replace the use of the hook, you just replace the hook"? [21:41:50] rofl [21:42:04] As I said above... [21:42:09] 13 releases isn't enough time apparently [21:42:12] (Sorry, couldn't avoid the Wittertainment reference.) [21:42:15] Indeed. [22:25:58] Is joins when doing db selects broken? [22:26:51] *are [22:26:57] wfGetDB( DB_MASTER )->selectFieldValues( [ 'revision', 'user' ], 'rev_id', [ 'rev_user != 0', '(user_id IS NULL OR rev_user_text != user_name)'], 'foo', [ 'ORDER BY' => 'rev_id', 'LIMIT' => $batchsize ], [ 'user' => [ 'LEFT JOIN' => [ 'rev_user=user_id' ] ] ] ); [22:27:06] Query: SELECT rev_id FROM `revision` `user` WHERE (rev_user != 0) AND ((user_id IS NULL OR rev_user_text != user_name)) ORDER BY rev_id [22:27:29] MW seems to be ignoring the options/join [22:29:58] /doing something weird with the tables [22:39:05] Looks like there's a comma missing between "revision" and "user" in that query as well [22:39:28] yeah [22:39:36] well, it shouldn't be in the FROM at all [22:39:51] in eval.php... [22:39:53] There's some notices [22:39:54] [Fri Oct 12 22:38:54 2018] [hphp] [650:7f7f2b89f3c0:0:000001] [] [22:39:54] Notice: Undefined index: 1 in /srv/mediawiki-staging/php-1.32.0-wmf.24/includes/libs/rdbms/database/Database.php on line 2562 [22:39:54] [Fri Oct 12 22:38:54 2018] [hphp] [650:7f7f2b89f3c0:0:000002] [] [22:39:54] Notice: Undefined index: 0 in /srv/mediawiki-staging/php-1.32.0-wmf.24/includes/libs/rdbms/database/Database.php on line 2562 [22:40:12] 2562 locally... [22:40:13] $joinedTable = $this->tableNameWithAlias( $table, $alias ); [22:41:37] on prod... [22:41:38] list( $joinType, $conds ) = $join_conds[$alias]; [22:41:57] Hmm so it's looking for an $alias that is not in $join_conds [22:42:36] https://www.mediawiki.org/wiki/Manual:Database_access#Wrapper_function:_select() - it's per the docs [22:44:11] OH [22:44:29] it's JOIN TYPE, [ 'stuff' ] [22:44:31] I've put a => [22:45:19] yeah that's better [22:45:24] * Reedy stab [22:45:24] s