[08:05:36] <dcausse>	 errand
[09:04:33] <gehel>	 dcausse: atsukoito might need some help to understand how to make changes to mw-config without breaking production. If you have time to pair with her today it would be great!
[09:04:51] <dcausse>	 gehel: sure!
[09:04:58] <gehel>	 thx!
[09:06:13] <atsukoito>	 dcausse: i'll get back from the meeting and send the details, basically i need to figure out how to test https://gerrit.wikimedia.org/r/c/1283711
[09:07:24] <dcausse>	 atsukoito: sounds good, I'll take a look at the patch
[09:42:16] <dcausse>	 sigh cindy's now failing "wikimedia/shellbox 4.4.0 requires guzzlehttp/guzzle ^7.9.2 -> found guzzlehttp/guzzle[7.9.2, 7.9.3] but it conflicts with your root composer.json require (7.10.0)" ... and can't repro locally
[09:45:19] <dcausse>	 seems similar to T426029
[09:45:19] <stashbot>	 T426029: Wikidata secondary CI broken: dependency conflict between guzzle and shellbox? - https://phabricator.wikimedia.org/T426029
[10:25:49] <dcausse>	 trying with composer install...
[10:25:54] <dcausse>	 lunch
[12:21:42] <dcausse>	 atsukoito: do you plan to ship https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1283711 during this afternoon backport window?
[12:31:21] <atsukoito>	 dcausse: i wanted to, yes
[12:34:53] * atsukoito is back from lunch
[12:38:54] <dcausse>	 atsukoito: I think you should add this wgOpensearchCredentials var to the private repo before deploying this patch
[12:40:18] <atsukoito>	 i don't know a procedure for this, and because it is a config change, i wanted to do it in the window
[12:42:27] <dcausse>	 hm... probable, I need to check the procedure, usually private repos are handled by sres but perhaps this one is OK to update for "mediawiki" deployers
[12:43:43] <dcausse>	 atsukoito: in the meantime do you have a snippet with the password redacted to double the check the shape of the shape of the wgOpensearchCredentials array?
[12:43:55] <atsukoito>	 i'm an sre but not the right kind of sre, so technically i have an access but i don't know the procedure
[12:47:19] <atsukoito>	 https://www.irccloud.com/pastebin/Y7J4Ozhc/
[12:47:35] <atsukoito>	 dcausse: this is how it should look like
[12:51:17] <dcausse>	 atsukoito: checking with the opensearch client but this seems correct
[12:51:52] <dcausse>	 yes, seems like it should work
[12:57:42] <dcausse>	 atsukoito: so you need to schedule the patch for the next window, this can be done by clicking "Schedule deployment of this change" on the gerrit patch
[13:02:39] <ebernhardson>	 \
[13:02:42] <ebernhardson>	 o
[13:02:48] <ebernhardson>	 awkward wave today :P
[13:02:56] <dcausse>	 o/
[13:02:58] <dcausse>	 :)
[13:09:40] <atsukoito>	 ebernhardson: hii ^~^
[13:10:55] <atsukoito>	 scheduled, thanks a lot for help!
[13:11:42] <dcausse>	 np!
[13:17:07] <inflatador>	 <o/
[13:19:04] <dcausse>	 o/
[13:45:46] <dcausse>	 I think I broke cindy again :(
[13:45:56] <ebernhardson>	 :) whats up?
[13:46:31] <dcausse>	 all red... seems like chrome can't access the wiki?
[13:46:37] <dcausse>	 unsure
[13:46:46] <ebernhardson>	 hmm, looking
[13:46:46] <dcausse>	 I can curl -v http://wikidatawiki.mediawiki.local.wmftest.net:8080/wiki/Main_Page
[13:48:47] <ebernhardson>	 hmm, should be `http://cirrustestwiki.mediawiki.local.wmftest.net:8080` but the log says `ENOTFOUND cirrustestwiki.mediawiki.mwdd`.  
[13:49:09] <ebernhardson>	 the question would be why...maybe something with the new mwcli version changing names?  Checking
[13:49:10] <dcausse>	 yes... was looking into this MWV_LABS_HOSTNAME
[13:50:04] <dcausse>	 or perhaps it's from mediawiki/extensions/CirrusSearch/tests/integration/config/wdio.conf.mwdd.js
[13:50:13] <dcausse>	 it has http://wikidatawiki.mediawiki.mwdd:8080/w/api.php
[13:50:58] <dcausse>	 should we update wdio.conf.mwdd.js to have mediawiki.local.wmftest.net ?
[13:51:11] <ebernhardson>	 dcausse: hmm, it should be reading wdio.conf.mwdd.js
[13:51:24] <ebernhardson>	 via the `WEVDRIER_IO_CONFIG_FILE` env var, at least it used to
[13:51:37] <ebernhardson>	 err WEBDRIVER_IO_CONFIG_FILE 
[13:52:06] <dcausse>	 $wiki.mediawiki.mwdd no longer work it seems...
[13:52:25] <ebernhardson>	 hmm, i guess it's possible it changed.  Seems reasonable to match to what we see now
[13:52:56] <ebernhardson>	 i use `http://cirrustestwiki.mediawiki.mwdd.localhost/` locally, not sure why but it's whats in my browser history
[13:53:24] <dcausse>	 with mwcli 0.30.1?
[13:54:04] <dcausse>	 I get a 503 with http://cirrustestwiki.mediawiki.mwdd.localhost/
[13:54:32] <ebernhardson>	 weird :S
[13:55:30] <ebernhardson>	 i guess it has to be http://wikidatawiki.mediawiki.local.wmftest.net:8080/wiki/Main_Page now
[13:55:36] <ebernhardson>	 or the related variants
[13:56:34] <dcausse>	 ok trying
[14:03:10] <dcausse>	 atsukoito: we can try to deploy your patch tomorrow morning 9:00 CET if you're around, might be less crowded hopefully
[14:05:06] <atsukoito>	 yes, I'll try jump in earlier tomorrow. today was a stressful attempt
[14:05:46] <dcausse>	 atsukoito: this patch is definitely not the easiest one for a first deploy :/
[14:06:11] <atsukoito>	 meanwhile, second take, https://gerrit.wikimedia.org/r/c/1286371
[14:07:40] <dcausse>	 +1, feel free to ping me and we can pair for the actual deploy
[14:08:17] <dcausse>	 definitely better with wikidatawiki.mediawiki.local.wmftest.net... not sure when that changed
[14:11:35] <dcausse>	 thinking about cindy running twice with 2 opensearch version, not sure how to handle the gerrit voting with barry...
[14:11:52] <ebernhardson>	 hmm, i'm not sure off the top of my head either. hmm
[14:13:05] <dcausse>	 perhaps an option to only -1 but allow the +1 only on the last call if the preceding one is successful
[14:13:33] <ebernhardson>	 yea that should work, skip the +1 the first time through and instead use it as a continue signal
[14:22:04] <dcausse>	 ah but it's barry running the full ./create-env.sh & ./run-integration.sh, I guess I can loop in barry and do all the logic there, somehow I thought we prepared the env before running barry
[14:22:56] <dcausse>	 merging https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CirrusSearch/+/1286369
[15:57:06] <dcausse>	 sigh... getaddrinfo EAI_AGAIN cirrustestwiki.mediawiki.local.wmftest.net...
[15:57:57] <dcausse>	 tempted to add *.local.wmftest.net to /etc/hosts ...
[16:12:23] <ebernhardson>	 i dunno if that would help, it has dns inside the docker-compose
[16:12:33] <ebernhardson>	 maybe?
[16:13:25] <ebernhardson>	 but very weird that doesn't work, it's a real dns that should always respond
[16:20:07] <dcausse>	 it must work it's only on a couple features, worrying that it's too slow or something
[16:22:12] <dcausse>	 yes seems like transient, I sometimes get curl: (6) Could not resolve host: cirrustestwiki.mediawiki.local.wmftest.net from the fresh container :(
[16:31:20] <ebernhardson>	 hmm, lucenes RandomAcceptedStrings, that turns automaton into a string accepted by the automaton, doesn't handle the awkward cases i added a generator for.  ran out of heap space on `cabbb{3}(ab{3}..+([d-e]becd{0,1}aababc[b-d]*){4})+` and `(ac..+decccb?){2}(eeeca{3}adeddca){4}ec`
[16:31:55] <dcausse>	 heap or stack overflow?
[16:32:01] <ebernhardson>	 java heap space
[16:32:19] <ebernhardson>	 i dunno how much it gives it, whatever intellij is doing
[16:32:38] <ebernhardson>	 it also took 2 minutes to run out of heap, vs a few ms to run the test on other strings
[16:32:59] <dcausse>	 hm could be a bug in your algo?
[16:33:27] <ebernhardson>	 no i re-ran with the seed, it generates the expression quick but then gets stuck generating a matching string
[16:33:51] <ebernhardson>	 in part because this expression generation is now O(1) for the number of AST pieces, it should be hard to get in trouble.
[16:34:53] <ebernhardson>	 hmm, the algo to generate the string is actually super small, can maybe figure something out
[16:46:51] <dcausse>	 dinner
[17:05:17] <ebernhardson>	 ended up making the generation cheaper, cap expansions at {3} instead of 4 seems to be ok
[17:22:21] <Trey314159>	 Im off to the dentist soon and I'll be out the rest of the day
[17:34:46] <inflatador>	 🪥
[17:37:58] <Trey314159>	 🦷
[20:36:50] <ebernhardson>	 hmm, got one test pass but it could just be lucky. 
[20:49:25] <ebernhardson>	 two in a row, from the world of "throw things at the wall until something sticks": UV_THREADPOOL_SIZE=32
[20:50:52] <quiddity>	 Hiyo. There's a question about search at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Cross-wiki_search_results%3F - I suspect the answer is just "That's very old!" - but I'm not sure where to link to, to prove it. The closest I can find is https://diff.wikimedia.org/2016/07/27/wikipedia-language-search/ via the blue-boxed link at https://www.mediawiki.org/wiki/Cross-wiki_Search_Result_Improvements -- Is there 
[20:50:52] <quiddity>	 anything better on meta-wiki/mediawiki that I can link to? (Or would you like to reply yourselves?)
[20:51:05] <ebernhardson>	 looking
[20:51:37] <ebernhardson>	 quiddity: yea that's probably been around for a decade.  Not sure what we have for docs
[20:53:08] <ebernhardson>	 at a general level we call it textcat, after the algorithm used.  There is a writeup at https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/TextCat_Re-optimization_for_enwiki but it's probably a bit technical
[20:54:00] <quiddity>	 Aye, that's linked in the blog-post. Okay, I'll just link to diffblog for now.  If y'all want to followup with more later, feel free. :>
[22:28:34] <quiddity>	 Followup question that I don't know the answer to: Why is this user only getting the interlanguage search results some of the time? 🤔 - https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#c-Suffusion_of_Yellow-20260512211000-Quiddity_(WMF)-20260512210700 -- (P.s. I'm out now, back tomorrow)