[00:31:16] https://phabricator.wikimedia.org/T419048 oop [00:33:01] sorry what [00:33:22] https://cdn.discordapp.com/attachments/1006789349498699827/1480362828249432134/image.png?ex=69af66d2&is=69ae1552&hm=e54006cdcafaf0c1b80f25a8000677a56ae3fc5839d91bda8e9d5cb54b5ba3b9& [00:34:03] mmmmm [00:35:06] is that for Parsoid? [00:35:10] they living on hopes and dreams fr [00:35:10] yep [00:36:47] What are you talking about? [00:37:00] ? [00:37:10] Parsoid is where hopes go to die and dreams burn into ash [00:37:18] tbf [00:37:30] much nicer developer experience than using legacy parser; but as a whole its a dumpster fire [01:12:34] [1/2] that's fun because PI still doesn't work :D [01:12:34] [2/2] https://rainverse.wiki/wiki/Rain:336:_Kissy_Talk?useparsoid=1 [01:16:24] soon™ [01:17:38] press x to doubt [01:38:57] has anyone thought of uh [01:39:39] limiting the number of attached accounts that can pop up at first when looking at a global account [01:40:35] because when you do it with a person whose been on a long time at miraheze, it lags the entire browser [01:40:37] or perhaps lazyloading the edit count? [01:41:18] iirc, most of the time is spent on external db lookups [02:08:39] It's a hell of a lot better than it used to be post-SUL3 [02:09:22] Used to be me and my 3k attaches could go be tea before adding checkuser to my account would finish [02:09:48] god if my computer runs the browser 5 seconds per frame looking at a bigass global account after sul3 i dont want to imagine before sul3 [02:10:02] It was very, very bad [02:10:15] Took me several minutes to log in every time [02:10:24] :xsob: [02:12:28] (this is only an issue for the oddities like myself who have a reason to have so many attaches) [02:12:47] Skye will know this pain in a few years [02:13:08] Pix too [02:13:42] hello it is me ms. gotta catch 'em all [02:15:26] obviously im only doing this volunteer thing because an user from a NSFW wiki asked for help and now I have to look like I'm helping everyone so it doesn't look weird when there's a few eyebrow raising wikis in my CentralAuth [02:21:10] meanwhile i'm just making contributions to degreesoflewditywiki [03:04:38] Regular reminder to express my gratitude for the existence of remote ManageWiki [03:12:01] It stems the tide [04:32:15] And with the Wiki. Bad joke. [09:22:34] Because it's not live 🤔 [09:22:46] ? [09:23:24] Miraheze is not running the patch for Parsoid PortableInfoboxes. [09:26:26] ah okay [09:32:58] 🔜 [10:20:26] what amount of compute does it take to run the full eventbus pipeline with kafka and changeprop? [14:45:48] Kafka requires quite a lot. Both Changeprop and eventgate dont require all that much. [15:16:23] How many broker nodes do you guys use [15:22:21] (RedPanda is probably an easier alternative if you don't have the resources available) [15:22:52] We might have enough [15:23:00] I'm prepared to give like 20 total GB ram and a few vCPU to it [17:00:56] we give it 20gb of RAM and 8 vCPU [17:01:11] is that on one broker or multiple [17:01:36] I suppose jobs aren't really something that need redundancy, it's ideal if they don't get lost but failure is presumably tolerable [17:01:49] One [17:02:01] But we will try and add another soon also. [17:02:17] alr I can prob get away with like 8GB ram and a few vCPU [17:03:08] We use 20GB RAM. It probably needs more than 8GB due to Java being so RAM hungry. [17:03:52] I'll toy around with it, we don't have that many events or jobs processed usually so it can probably manage with a handful [17:06:20] realistically the amount of data that it will have to process will be so small I can run it on hard drives [17:06:45] we have one server with ssds but the resources on that are constrained somewhat so I prefer to use that for databases and mediawiki itself [17:33:57] @pskyechology @posix_memalign https://issue-tracker.miraheze.org/T14896#301709 btw [17:35:01] pr #777? we dont need any "lets gamble, try merging", you can just directly push to prod [17:35:07] /j [17:35:51] looks promising though [17:41:23] It's gonna be hard to reproduce and test since there's some race condition involved. As long as it doesn't make things worse we can monitor new reports of things being broken? [17:41:36] Or we spawn lots of test wikis on beta and see how they do. [17:41:38] It cant be tested on test151. [17:41:52] It in theory is never reproducible on beta. [17:42:19] Because jobs always run on the same server ManageWiki is changed on. [17:42:40] Thats when it happens on prod. When jobs run on a different server since changing ManageWiki does reset cache on the current server. [17:43:07] Unless there is some other race condition as well. [17:43:15] the forbidden prod wiki spawner [17:48:04] That reminds me: I still haven't wiped https://defaultextensiontest.miraheze.org and https://defaultextensiontest2.miraheze.org from the database since I deleted them on a machine without my ssh keys. Doesn't really matter though as they are more-or-less empty. [17:49:14] I vaguely remember TitleKey not working when testing the 1.44 upgrade. It fixed itself after some disabling/re-enabling. Not too sure about events that happened 9 months ago, though.