[20:14:48] brion: I don't know how far you are on the actor table change, but I put the WIP of my comment table change in Gerrit in case you'd find it helpful. [20:15:27] Excellent [20:22:35] anomie: looks nice, I like the wrapper for the load/store and the updated beigng reusable as a maint script [20:22:42] I'll do a closer review later [20:22:57] And/or blatantly rip it off for the actor updater ;) [20:23:29] It's more the maintenance script is usable by update.php, IMO ;) [20:23:30] feel free to blatantly rip things off, that's much of why I posted it. [22:24:08] Anyone have an idea of how uselang + file pages + parsercache would all come together? https://phabricator.wikimedia.org/T167465 [22:24:18] Spotted that today, pretty nasty failure mode [22:37:25] curious [22:38:04] doesn't look very file-page-specific offhand [22:38:29] yeah i can do it on https://commons.wikimedia.org/wiki/Main_Page?uselang=%E2%A7%BCLang%E2%A7%BD too [22:38:38] "input validation is hard" [22:45:45] RequestContext should already be sanitizing it... [22:46:04] yeah... something must be grabbing it directly? [22:47:27] how do you get in the first place? lang is a valid message name [22:47:30] ForeignAPIRepo.php [22:47:58] well... I guess its jsut making sure there is one [22:51:05] * brion pokes vagrant until it boots properly [22:51:29] sigh. I wish I knew what was causing that ssh hang [22:51:48] RequestContext only santizes if you use getLanguage() [22:52:08] hmmmmmmmm wait, we don't have any weird shit on Commons like a custom plugin to append uselang into the parser cache hash do we? [22:52:12] anything that does >getVal( 'uselang' ) has to remember to sanitize [22:52:34] i ask cause no failure on https://en.wikipedia.org/wiki/Main_Page?uselang=%E2%A7%BCLang%E2%A7%BD [22:53:33] hmmm.... that is suspious [22:54:12] if only we had all config in a central repo and a diff tool for it... [22:57:28] don't _see_ anything relevant in wmf-config [22:58:48] tgr: Could easily be some weird gadget on Commons. [22:59:03] Which could explain why it's not breaking on a wider scale & also not affecting enwiki [22:59:12] ParserOptions::initialiseFromUser takes $lang as an option [22:59:13] Wait, no, that doesn't explain the latter [22:59:14] Only former [23:11:30] hmmmm, ULS pokes at 'uselang' directly and can do some overrides [23:11:36] could be a diff in config there [23:11:39] huh, all the requests seem to be from bingbot [23:12:11] oh bing :D [23:19:28] * RainbowSprinkles headdesks [23:19:37] So it's just bing doing dumb stuff to commons [23:19:38] Ok [23:20:23] well, regardless of thwere the evil links come from they shouldn't be erroring out like that :D [23:20:35] it's worrisome [23:22:44] Yeah, indeed. [23:22:54] But "bing being dumb" means I don't block the train for it. [23:23:06] Vs: something's that's breaking for users actively :) [23:24:06] \o/ [23:24:23] still, unsantized data getting to low levels of the system is bad [23:24:37] Yeahhh. I did a wtf when I spotted that. [23:24:38] :D [23:24:51] on the plus side our memcache layer roundly rejects it before it ets into cache [23:24:55] so .... not the owrst thing [23:24:56] userlang=pooooooooooooop shouldn't get all the way down into the parser cache request code [23:25:31] uselang=🖕 [23:26:22] We could specify language codes using country flag emojis. What could go wrong? [23:26:30] uselang=🇫🇷 [23:26:41] sounds legit [23:26:57] except for *cough* countries are not languages *cough* :D [23:27:05] * brion blames canada [23:27:14] OH OH [23:27:23] zero-width nonjoiner [23:27:28] * RainbowSprinkles moves en.wikipedia.org to 🇺🇸.wikipedia.org [23:27:39] also this is my new favorite category https://commons.wikimedia.org/wiki/Category:The_finger_(gesture) [23:28:29] Um, how is https://commons.wikimedia.org/wiki/File:2009-365-48-_Facebook_FAIL_(3287111536).png possibly CC0? [23:29:08] hahahahahahahahah [23:29:32] NC fail [23:30:24] and uploaded by Fae! [23:31:55] that !userlang=JUNK has to be coming from the PageRenderingHash hook. Nothing in ParserOptions uses the "uselang=" label when building the hash [23:32:47] bd808: on the hash end it's userlang (with R), beware your searches :D [23:33:08] it's an option that's left off the hash when it's the default [23:34:04] hmmm.. "userlang" is in legacyOptions() [23:36:17] but even that would add "'!' . $this->mUserLang->getCode()" to the hash [23:36:58] yeah this is making me wonder if something is injecting a raw uselang value into $wgLang/etc or directly into the user's settings [23:37:02] that wouldn't make "!userlang=⧼lang⧽" happen would it? [23:37:38] the "userlang=" part in the hash seems off [23:37:44] if it's being used in non-legacy mode then i think it appends the full name no? /me looks again [23:39:01] i see what would become "!⧼lang⧽" in optionsHashPre30 [23:39:11] are we using ... not-pre30? :D [23:41:41] LanguageConverter would just add !$variant too [23:42:11] * bd808 is digging blindly in code he's never really read [23:47:28] wikibase/wikidata split the cache on userlang which is expected [23:50:44] suspicious [23:52:58] ok i can repro a bogus value on an individual page in vagrant, though it doesn't trip the exception [23:53:34] if i use {{int:mainpage}} on a page, it forces it to add !userlang=whatever [23:53:47] though .... for me it's urlencoding [23:55:56] so i get like "wiki:pcache:idhash:1-0!userlang=%E2%A7%BClang%E2%A7%BD" [23:56:18] so if {{int}} does it then should be able to also trigger on meta? [23:57:13] yup. meta's mainpage does it too [23:58:17] whee