[20:22:15] Pchelolo: duesen Did much of your permission work actually get plumbed into MW? [20:22:25] https://phabricator.wikimedia.org/T273317 https://phabricator.wikimedia.org/T273296 [20:22:34] These seem.. suspicious, but might just be coincidental [20:23:33] Reedy: only rest API was massively changed. Out of non-rest-api, the only change is this one: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/654511 [20:24:26] the rest of the code we merged is just new classes which are not used [20:24:34] lemme look at tickets [20:25:01] Yeah, that's what I meant by "plumbed in" :) [20:27:35] Reedy: can the permissions changes made after centralauth ipbe broke be causing those flaggedrevs issues? [20:28:19] Possible. I'd have to look at the patches to see [20:28:21] Urbanecm: ^ fyi it being discussed in here too [20:29:35] is it being discussed somewhere else too that I'm not seeing or was that a general for awareness ping? [20:30:36] Not actively discussed, but it had been mentioned in the stewards irc channel [20:30:51] Where I also helpfully suggested we just undeploy FR ;) [20:30:53] Urbanecm seems right. this is this change: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/657419 - forgot this one got plummed it too. The difference here is before we were getting globals directly, now it's getting them via ServiceOptions.. [20:31:41] Lets see if it cleanly reverts onto the branch then :D [20:45:32] thanks for the reverts Reedy :) [20:45:58] Urbanecm: Want to help test? [20:46:13] When CI decides to getthings finished [20:46:16] Reedy: I think I'm still able to reproduce on test2wiki with my testing account [20:46:18] so, sure [20:46:32] * Reedy +2's the patch to try and speed up the process a little [20:46:42] that usually helps :D [20:47:43] I was waiting for the first round of CI to finish... But it's not the fastest thing in the world ;) [20:48:04] yeah :/ [20:48:20] just logged to the acc again, it's still broken (how surprising :)) [20:48:32] Reedy: ping me once available at some mwdebug srv [20:48:36] I think that's better than it suddenly being fixed... [20:48:45] at this point, definitely :) [20:49:20] you dont like UBN!s magically disappearing? [20:49:43] no, because it means they can magically re-appear Majavah [20:50:19] don't they magically reappear even if they don't magically disappear? [20:50:40] sometimes, they do, but the probability is higher if they also magically disappear [21:53:40] Pchelolo: Reverting that patch doesn't seem to have made any difference [22:55:17] Urbanecm: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/654718 would be the other suspicious one I guess [22:55:34] looking at it [22:55:47] It's doing stuff with User::changeable(By)Groups [22:56:13] definitely [22:56:27] I'm 80% sure reverting this patch will fix it too [22:56:49] as I said on the task, the serviceoptions' version of AddGroups was _itself_ broken [22:57:02] (I have no idea why, or which other configuration variables can be broken in a similar way) [22:57:15] the old version just uses global $wgAddGroups; [22:57:27] that...can behave differently? :D [22:58:50] bugs? in software? never [22:59:40] I'm more convinced reverting this patch will at least conceal the bug (which is "why the hell serviceoptions got bad config") than with the other patch, that is [23:01:13] it's possible if some code is still using globals and some is using config... [23:01:18] there ends up being some amount of discrepenacy [23:02:23] sounds plausible [23:03:11] especially when we have addgroups/removegroups in extension.json too [23:03:32] For some stuff... don't we do merging of globals and $config->get() [23:03:40] no idea [23:15:19] did you work out if it was replicable locally? [23:21:38] not yet [23:21:42] but I'll try it