[02:47:01] sysrq+f is amazing [02:47:22] F stands for "do your f***ing job, stupid kernel" [03:29:00] TimStarling: if Quiz logic is in your mind, might be easier to review https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Quiz/+/453989/ as well. [03:29:21] no high prio though, don't know if it's easy to check [03:34:03] err, nvm, seeing the other thing now [13:21:51] anomie: DanielK_WMDE_: I have deployed wmf.20 to all wikis :] [13:22:20] there was some PHP warning due to parser cache output being obsolete when transitioning from .19 to .20 https://phabricator.wikimedia.org/T203567 [13:22:29] but that did not seem worthy to block train on that [13:25:22] and that might well be related to https://phabricator.wikimedia.org/T156541 [13:50:00] hashar: ah, yes. a new member in ParserOutput. that would break php serialization [13:50:23] hashar: i have a fix for T203583, working on a regression test [13:50:27] may be wirth a backport [13:50:35] T203583: {{subst:REVISIONUSER}} no longer substitutes into the current user name, but the username of the last revision - https://phabricator.wikimedia.org/T203583 [13:50:37] this stuff is hard to test :/ [13:58:45] DanielK_WMDE_: for sure :/ [13:58:56] if I see some activity on the task, I will be happy to hot deploy it tonight [13:59:40] and maybe we can start considering namespacing memcached based on the wiki version, but that would be an havoc to start with a cold cache :-\ [13:59:44] anyway I am off, bbl [14:13:21] hasharAway: i'd love to just kill php serialization [14:14:03] hasharAway: or do it the java way: have a SERIALIZATIONVERSION class constant that you have to bump when touching members, and include it in the cache key. [14:14:31] (doesn't work for nested objects, but would at least catch *some* of these errors) [14:14:54] even changing the order of members, or changing the access modifier breaks serialization. [14:14:57] it'S rather annoying [14:20:42] DanielK_WMDE_: I was just made aware of https://phabricator.wikimedia.org/T203661, do you think it's MCR related? [14:27:21] greg-g: so, the parser output keeps the old

title, is that the issue? [14:27:49] i'll investiage [14:28:18] thanks! [14:44:51] greg-g: the fix for https://phabricator.wikimedia.org/T203583 should be complete now [14:45:04] looking into the page rename thing now [14:50:42] * DanielK_WMDE_ grumbles about T203583 really beign two entirely separate problems [17:28:35] tgr: anomie can one of you review/merge https://gerrit.wikimedia.org/r/458526 it's a patch for an UBN! [17:28:59] * anomie looks [17:31:44] RoanKattouw: hey, These are for you when you have some free time: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/457974 https://gerrit.wikimedia.org/r/c/mediawiki/core/+/457978 https://gerrit.wikimedia.org/r/c/mediawiki/core/+/456027 [17:32:44] Will review in a minute [17:32:53] Thank you! [17:55:52] tgr: anomie : seems Daniel left... I was going to ask, do you know the impact of `PHP Notice: serialize(): "" returned as member variable from __sleep() but does not exist` [17:55:59] comes from SqlBagOStuff->serialize(ParserOutput) [17:56:07] started happening lots when we tried to revert from wmf.20 to wmf.19 [17:56:17] Krinkle: I'll try to look in a minute or two. [17:57:11] looks like something is using an empty string as key in an object which looks like a bug, ParserOutput is meant to be forward and backwad compatible for at least 1 version, I don't know whether it is safe or not to rollback with this PHP Notice. [17:57:28] currently we're building up a growing backlog of broken revision text due to subst: doing the wrong thing. [17:57:42] Krinkle: I just merged the patch for fixing that one [17:57:45] Rollback should happen asap but is blocked on determining whether this PHP Notice spike is acceptable [17:58:04] I guess backport to wmf.20 for that and sidestep this issue [17:58:12] which made scap not rollback past canaries [17:59:08] anomie: this was also on that same task, is it needed? https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/458526/ [17:59:49] greg-g: That's for T203661, not T203583 [17:59:49] T203661: Old page title is displayed after renaming a page until the page is subsequently edited/null edited - https://phabricator.wikimedia.org/T203661 [17:59:50] T203583: {{subst:REVISIONUSER}} no longer substitutes into the current user name, but the username of the last revision - https://phabricator.wikimedia.org/T203583 [18:01:03] anomie: ok, backporting to wmf.20 and will test on mwdebug [18:01:33] anomie: the commit you merged has a test for the bug so looks good, but https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/458526/1 was also tagged with that task, is that commit also needed? [18:01:54] Krinkle: That's for T203661, not T203583 [18:01:57] OK [18:02:11] Does that affect view only, or also PST? [18:02:16] * anomie is looking at that one now, and is about to propose an alternative fix. [18:02:20] Thanks [18:02:21] That's only view, a purge fixes it. [18:02:24] cool [18:02:31] I'll move on without that for now then [18:06:58] anomie: doh, thanks :) [18:07:24] I blame daniel for tagging the wrong task :) [18:10:23] Krinkle, greg-g, tgr: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/458547 is my alternative proposal for T203661 [18:10:24] T203661: Old page title is displayed after renaming a page until the page is subsequently edited/null edited - https://phabricator.wikimedia.org/T203661 [18:17:40] anomie: yeah, that looks nicer [18:18:21] the sanity checks in the other patch are worth having but adding an extra parameter to revision rendering just for this edge case feels hacky [21:58:33] deployed ^ [22:16:16] Most of the settings needed [22:16:16] * for rendering normal pages are UserGetRightsset in the cookie to minimize use [22:16:16] * of the database. [22:16:23] UserGetRightsset? Is that missing a space? [22:16:32] or a hyphen