[13:33:43] DanielK_WMDE: I ran into this email recently, do you think it could be MCR related? https://lists.gt.net/wiki/mediawiki/887834 [13:35:42] I mean, obviously it is related, but is it an MCR-related bug, or just a messed up wiki failing in new ways? [13:49:55] tgr: looking... meanwhile, do you see anything suspicious here? https://performance.wikimedia.org/xhgui/run/view?id=5b3a23a43f3dfaf3013fe2fa [13:51:33] tgr: that looks like something is not falling back to looking up the default content model. i'll see if i can find it [13:52:08] oh wait no - it's trying to look it up... that's strange. [13:54:44] DanielK_WMDE: I doubt an xhprof run would tell much without having a baseline run to compare against, but the bug Aaron spotted is a pretty likely cause of the save time increase anyway [13:54:55] that's not one stack trace, that's two stack traces, interleaved. so nice to read. [13:56:18] tgr: that bug effectively disabled the edit stash. yea, that would do it, i guess. I'll poke at the test failure next [13:56:50] the test failure appears on other patches as well, I think it's fine to just force it through [13:59:33] tgr: i just gave it a +2, if you want to override jenkins, sure :) [14:00:57] although it does not seem hard to fix the test [14:02:45] tgr: re that email: the only explanation I jave is that they have an empty string in rev_content_model for some reason. the fix is to replace all empty strings with null. [14:02:56] why can i reply to the email? it doesn't seem to be on wikitech [14:03:13] it's from mediawiki-l [14:04:01] the question is, is this something widespread (caused by some extension maybe) that might affect a lot of other wikis when they upgrade? [14:04:04] ah, i'm not subscribed there, i think [14:04:16] yes, it'S worth monitoring [14:04:42] maybe we could file a bug and have a nice error message for empty strings that points there? [14:05:28] re fixing the test - that would of course be great - do you understand the problem? [14:05:40] I see Уреди -> Уредите [14:05:52] that's singlular -> plural, right? [14:06:27] where does that come from? how did it get in?... [14:08:25] DanielK_WMDE: T198625 [14:08:25] T198625: MediaWiki core patches fail with: ParserIntegrationTest::testParse with data set "parserTests.txt: -{}- tags within headlines (within html for parserConvert())" - https://phabricator.wikimedia.org/T198625 [14:08:57] I'll update the test [14:20:10] tgr: thank you :] [14:32:34] anomie: replied to you in https://phabricator.wikimedia.org/T198413#4384839 [14:33:13] am i missing something? i don't think we can avoid the "if we roll back, we lose access" situation. we can only try to mitigate the fallout. [14:37:22] DanielK_WMDE: I think the important thing is to be aware that such a rollback will break things, both for us and for people on-wiki who might start using this while a rollback is still a possibility. [14:38:07] e.g. so no one runs a bot removing license data from wikitext in favor of SDC until we're sure the rollback won't happen. [14:39:41] anomie: oh, I agree! It just sounded to me like you were advising against the change, though. [14:40:03] i see no way to make the migration step less risky. [14:40:13] Sorry for the confusion. [14:40:15] but the risk shoud be noted clearly on the ticket. i have added a not accordingly [14:40:32] anomie: https://phabricator.wikimedia.org/T198308 [14:40:55] do you think the NOTE is enough? or shoudl this be a warnign? [14:41:19] I already put one on https://phabricator.wikimedia.org/T198312 [15:10:10] tgr: do yyou think this warrants a swat? https://gerrit.wikimedia.org/r/#/c/443408/ [15:12:40] DanielK_WMDE: yes. If nothing else, to see how it affects save timings without all the wmf.11 confounders [15:18:26] tgr: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/443439 [15:47:26] DanielK_WMDE: I added one more sentence to your note. [15:47:54] DanielK_WMDE: are you bringing it to SWAT or should I? [15:52:22] anomie: ok, thank you! [15:52:43] tgr: go ahead :) [16:01:35] * DanielK_WMDE frequently makes auto-correct style typos, even without auto-correct... [16:41:02] DanielK_WMDE: I forgot to say at the last checkin, I'll be at a wiki event Thu-Sun and not working; and Wed is a WMF holiday; and I have some moderately urgent admin stuff to do, so... how urgent is the diff patch? [16:41:48] it's probably the only thing blocking phase 1, but AIUI phase 1 has now become a fairly arbitrary point on a board, not a real blocker [16:42:20] there is a quick way to fix that patch, which is basically the current code minus inheritance, and a nice way with wrappers [17:03:29] tgr: it'S not totally urgent, but i'm curious to see the "quick way to fix the patch". [17:03:55] tgr: other than that, it would be great if we could get https://gerrit.wikimedia.org/r/c/mediawiki/core/+/442153/8 in [17:04:06] and maybe even https://gerrit.wikimedia.org/r/c/mediawiki/core/+/442903/4 [17:04:27] orr. "unused use statement". [17:04:54] anomie: i'm touching up the PageArchive patch at the moment, shoudl, be ready for review tomorrow [18:49:51] Krinkle: I made a snapshot with the X-Wikimedi-Debug XHProf profiler: https://performance.wikimedia.org/xhgui/run/view?id=5b3a66b9bb8544e2017bac8d [18:50:12] which claims 1.5 sec wall time (which sounds reasonable) [18:50:35] then I click at view flamegraph, and the bottom bar of the graph shows 48 sec [18:50:48] is tgar functionality not reliable? [18:59:35] tgr: The flamegraph within xhgui is crapped, always has been. It's recursively adding up all child nodes to compute the self-time which is wrong. [18:59:53] So small and big nodes are extremeified. [18:59:58] what's the best way to add a resource (css/js) to a special page? [19:01:45] tgr: I've been working with upstream perftools/xhgui for a while off and on to make it work, but the issue is also with the xhprof data itself. It's not a perfect tree, it has a flat record of pair relationships etc. A=>B and B=>C, but the total time and call count of B=>C is not limited to those originating from A=>B=>C but also X=>B=>C etc. [19:02:14] the tree maker solves for this by splitting it evenly between the different possible parents. [19:02:28] Which is wrong, but also means that some node have a child that is bigger than themselves. [19:03:00] It seems that when xhgui's flamegraph viewer was made, they thought this fact meant that the self times were not inclusive, and to avoid an obviously broken visualisation, they decided to add up recursively. [19:03:12] But the result is that numbers and proportions are all wrong [19:03:37] Details at https://github.com/perftools/xhgui/pull/216#issuecomment-344154508 [19:09:11] interesting, thanks for the historical background [19:09:39] davidwbarratt: ResourceLoader, same as non-special pages [19:10:24] tgr ooo! thanks! [21:25:04] MaxSem: reminder on https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Scribunto/+/438194/ :) [21:25:32] meh, need to get around to these [21:25:43] not totally forgotten, don't worry