[01:33:50] Reedy: James_F: so $this->setExpectedException() is gone in PHPUnit 6... https://codesearch.wmflabs.org/search/?q=setExpectedException&i=nope&files=&repos= [01:34:36] Fun. [01:34:42] Is there a replacement? [01:34:55] $this->expectException() [01:34:57] We just added a use of that on Thursday. [01:35:19] I think we can provide back-compat in MediaWikiTestCase for now [01:35:24] Aha. Was that available in 4.8 or are we going to have to add a huge number of ifs? [01:35:31] Right. [01:35:36] it's 5.2+ [01:35:40] Fun. [01:35:47] Make a task? [01:36:11] we're still stuck on [01:36:12] 01:35:50 PHP Fatal error: Declaration of MediaWikiTestCase::run(PHPUnit_Framework_TestResult $result = NULL) must be compatible with PHPUnit\Framework\Test::run(PHPUnit\Framework\TestResult $result = NULL) in /home/jenkins/workspace/mediawiki-phpunit-php70-jessie/src/tests/phpunit/MediaWikiTestCase.php on line 17 [01:36:39] Meh. [01:37:06] I think we can class_alias our way around it... [01:37:07] Make MWTestResult similarly? [01:37:12] Or that. [01:39:47] if ( !class_exists( PHPUnit_Framework_TestResult::class) ) { [01:39:47] // Support both PHPUnit 4.8 and 6.5.x [01:39:47] class_alias( \PHPUnit\Framework\TestResult::class, PHPUnit_Framework_TestResult::class ); [01:39:47] } [02:12:20] https://gerrit.wikimedia.org/r/#/c/394851/13/tests/common/TestsAutoLoader.php I cheated [02:17:00] https://integration.wikimedia.org/ci/job/mediawiki-phpunit-php70-jessie/65/console ok, real failures now :) [16:58:15] legoktm: Is there a general task for "make all deployed extensions and their unit tests pass in PHP 7" yet? [16:58:34] don't think so [16:59:23] according to https://tools.wmflabs.org/ci/last_run.html everything is passing except extensions that have tidy parser tests, which is going to be fixed by the Remex change [16:59:32] Yeah. [17:00:12] Well. It says "none" for PageImages despite me just +2ing a patch for fixing them. [17:00:22] it updates every hour [17:00:29] at uh :12 I think [17:00:36] Kk [21:35:39] MaxSem: have you seen https://phabricator.wikimedia.org/T183759 ? [21:36:36] will look tomorrow evening on my windows machine [21:36:42] *today [21:41:38] James_F: Well most of those have NONE :p [21:41:50] It's not failing so it must work ;-) [21:50:32] no_justification: That's not my view. :-) [22:57:44] TimStarling, Krinkle https://phabricator.wikimedia.org/T187833 needs investigation again .. not sure where I should be looking now. [23:03:04] subbu: I guess we should find a way to patch the parser to not fatal on that particular bit of wikitext. [23:03:20] It's the same bug though, I've added a non-fatal diff link to the phab task [23:05:16] interesting .. yes. [23:09:58] let me see if I can reproduce it locally [23:13:30] It's odd that the abuser found a similar diff, also from years ago [23:13:40] It's not like he/she is adding these anew [23:14:04] Also, I suspect that adding them anew might not work if it fatals, depending on whether we parse before or after revision saving in MW save path [23:14:24] I know we do secondary link insertion post-commit, but not sure about initial parse [23:14:26] Looks like some bot crawling old revisions? [23:14:52] twentyafterfour: Can you help making https://phabricator.wikimedia.org/T187833 NDA-only visible? [23:15:02] Just want to avoid the abusing/OOM text being too widely visible just in case [23:15:08] I can't figure it out.. [23:15:13] Krinkle: "protect as security issue" [23:15:20] Krinkle: just use the security issue button ;) [23:15:24] on the right side, under edit task etc [23:15:26] Ah, we have that [23:15:28] Thanks! [23:15:30] :) [23:15:52] TimStarling, doing it once, twice, thrice .. and looking at the expandtemplates output shows that the size of the output starts blowing up rapidly. [23:17:49] roughly 4^(nesting level-1) * 4k [23:17:53] the post-expand include size is meant to limit massive preprocessor expansions, but I guess strip marker expansion is not included [23:20:54] TimStarling: Hm.. do we use strip markers for template parameters like {{{1}}} etc.? I thought maybe the expansion is big because of the recursion there. [23:20:58] BUt afaik we don't use stripmarkers for those [23:21:34] no [23:21:53] there's a separate limit for argument size exactly for that case [23:22:28] but the backtrace always shows OOM in StripState, right? [23:22:49] Seems so, yeah [23:23:07] TimStarling: For what it's worth, the same abuser made similar edits a few more times in that year (see user name/contribs) [23:23:16] 2008 [23:24:22] Hm.. suppose our current limits don't allow this, do we enforce those limits when viewing existing revisions? Or only when saving and/or eval'ling via action=parse. [23:24:40] We do it always now, right? [23:27:24] limits are enforced on view/parse only, expansion just stops when they are hit so you get a page full of errors [23:28:02] we could do clickthrough warnings, since we have a facility for that now, but I don't think it has been done [23:28:25] I mean on save [23:28:41] Right, so bottom line is that if our current expansion limits were to not allow this wikitext, then viewing the oldid would not fatal. [23:28:48] Which means our current limits do allow this. [23:29:05] We don't case-by-case enable/disable limits based on how the parser is invoked, right? [23:29:39] right [23:30:15] Hm.. didn't we also block the bot in question last week? [23:30:21] So this is a different bot? [23:30:24] Or did they change the UA? [23:30:43] i don't think we found what bot that was, did we? [23:32:25] Right [23:32:28] I remember now [23:32:33] Indeed, it's ua was just "ruby" [23:39:34] we didn't block it [23:40:02] the IP address would have been enough, it's some sort of server in a university media studies department [23:40:37] revdel was an alternative to blocking it [23:41:32] Right [23:47:49] since the request pattern is apparently good faith, I didn't want to block it unnecessarily