[00:02:29] Reedy: semi-random question -- do you think that Extension:UserMerge would work on Wikitech? [00:03:32] its not installed there now because InitialiseSettings.php blocks it for wikis in the "nonglobal" dblist [00:16:51] * bd808 found the discussion of undeploying UserMerge and is now trying to think of alternatives [00:19:39] are there multiple users per LDAP account? [00:20:26] in theory I don't think there's a reason UserMerge couldn't be redeployed [00:20:50] it's the part of it that lives in CentralAuth that was problematic [00:21:00] that was known to be problematic, anyway [00:25:03] tgr: yes, there are currently 73 developer accounts (LDAP records) which have 2 or more local accounts on wikitech. I just pushed the config change today that should stop that number for growing. [00:25:45] Now I'd like to cleanup the user table so that we don't have other problems in the future (like when I finally get to the point of doing an SUL merge there) [00:25:55] I'd just permaban the ones with the incorrect casing and be done with it [00:27:03] there's a "fun" issue with that now too. There are hooks that disable the LDAP record and any associated Phab account on permaban. [00:27:25] and those are case insensitive? [00:27:33] yup [00:27:53] Anyone got logspam they found or helped fix past month that might be interesting for the Excellence monthly? [00:27:58] set up some manual ban then [00:28:38] tgr: yeah, that's an option I thought of. Timed ban until the year 3k or something goofy like that [00:30:15] I'll think about it some more. There's no super urgent need for the cleanup [17:06:01] anomie: i always enjoy when your when your emails are in-reply-to something from five years ago. [17:06:30] (: [18:16:31] duesen: poke as requested - https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/414968/ [21:30:47] James_F: I'll poke about in the wikitech database and try to figure out all the pairs and which one should "win" the merge [21:44:13] RoanKattouw: do you know if EchoEventLoggingVersion is still something Echo needs, or is it obsolete and/or redundant with schema revision? [21:44:31] Looking at it on all page views in HTML, could file a task to migrate, but maybe it's something that is low hanging fruit for removal. [21:44:41] I don't particularly know who/what consumes Echointeraction events [21:53:24] bd808: Cool. [21:53:32] bd808: Want me to deploy it now? [21:54:13] sure, whenever you are ready to do so [21:54:38] it should be a pretty safe thing (until we start using it at least) [21:55:06] Yeah. [22:18:09] Krinkle: EchoInteraction is mostly for analysis, it's not being looked at right now, but I just suggested to Morten that he should look at it half an hour ago [22:18:41] The version variable is not technically redundant with the schema version because it's meant to be for big changes in Echo that change what the data means / what the interactions are [22:19:04] But I'm not sure it's ever been incremented, and maybe it should be a static var (like a cache version) rather than a config [22:19:07] RoanKattouw: I'm assuming the version field exists in case major changes are made so that one can conveniently query only newer or older data without relying on timestamps. seems like schema revision should do for that, although in some cases you may want to match multiple versions in that case. [22:19:15] Oh yikes it's in all HTML page views?! [22:19:17] it's been static since 2016 when it was refactored. [22:19:47] yeah, could be moved to startup to make it async and further bundled with the module - if needed. [22:19:57] OK so maybe it can be hardcoded in the JS instead [22:20:06] there is also an 'enabled' flag, which I suspect exists from before mw.track was a thing, but not sure. [22:20:07] Or yeah bundled in with the module [22:20:33] right, yeah, hardcoding with code isn't a bad idea. given that's where the implementation is, you dont' want that configurable anyway [22:21:05] RoanKattouw: okay, I'll create a task. Thanks :) [22:25:26] bd808: https://wikitech.wikimedia.org/wiki/Special:UserMerge now live (for bureaucrats only). [22:29:40] thanks James_F! I think I can dig up a "test" account to merge before we move on to active users [22:29:47] Cool. [22:29:51] * bd808 pushes another task on the stack [22:30:00] :-) [23:09:08] James_F: the very first one I tried blew up with a DBTransactionSizeError -- https://logstash.wikimedia.org/goto/c238717d6418736be27f447198acb6e1 [23:10:45] Hmm. Maybe we should shift the limit out for wikitechwiki for a bit. [23:11:01] Did the accounts you were merging have lots of edits? [23:11:17] less than 500 each [23:11:54] Hmm. Maybe the DB is particularly slow. Odd. 5 seconds to rewrite 500 rows of revision and log is a lot. [23:11:56] https://wikitech.wikimedia.org/wiki/Special:Contributions/Gwicke merging into https://wikitech.wikimedia.org/wiki/Special:Contributions/GWicke [23:12:03] Right. [23:14:39] wikitech's db is on the m5-master in the misc cluster. It could be somehow horrible in perf and we would probably not notice very often. [23:16:34] Maybe.