[10:01:21] <dcausse>	 lunch
[11:26:20] <atsukoito>	 thanks dcausse for trying to roll out the translate credentials. i'll ask Niklas (Nikerabbit) what we can do next
[12:04:29] <dcausse>	 atsukoito: np!
[12:58:48] <ebernhardson>	 \o
[12:59:57] <dcausse>	 o/
[13:00:14] <dcausse>	 meh cindy api tests enable rewrites by default?
[13:00:45] <dcausse>	 investigating a random failure and found "rewrittenquery":"waffle squash" in the response
[13:00:58] <ebernhardson>	 hmm, the dym rewrites? i suppose that is a default
[13:01:23] <dcausse>	 for the api?
[13:01:57] <ebernhardson>	 hmm, i guess i don't remember the api exactly
[13:02:06] <ebernhardson>	 web certainly does
[13:02:30] <dcausse>	 hm... from page_steps: options[ prefix + 'enablerewrites' ] = enableRewrites ? 1 : 0;
[13:02:54] <dcausse>	 but only when you have " with rewrites enabled" in the test...
[13:02:59] <ebernhardson>	 hmm, indeed
[13:06:38] <ebernhardson>	 should be able to make it spit out urls before accessing them or something, probably very spammy though.  It used the print the api req/response/url on fail but i feel like i haven't seen that recently
[13:20:02] <dcausse>	 seems like srenablerewrites is not honored by mw, I set 0 or 1 and it's always enabled
[13:20:14] <ebernhardson>	 oh! well that's a good find
[13:20:30] <dcausse>	 ah I think cindy does it wrong
[13:20:42] <dcausse>	 it should not pass enablerewrites if not enabled
[13:48:44] * ebernhardson wonders if `page_kind` or something else would be better than `page_type`.  We just use the word type a lot :P
[13:53:13] <dcausse>	 :)
[13:53:27] <dcausse>	 or is_redirect: bool but it's very narrow
[13:53:51] <ebernhardson>	 hmm, maybe that would be better. I suppose i went with the string because it gives flexibility, but i don't know what else could go there
[13:53:51] <dcausse>	 page_kind would allow something else than page/redirect 
[13:54:01] <dcausse>	 yes same
[13:54:17] <ebernhardson>	 i suppose it's also more error prone, some query with page_type => redircet
[13:54:28] * ebernhardson should use more constants to avoid that i guess :P
[13:54:49] <dcausse>	 true but hopefully it's only controlled by cirrus
[13:55:09] <dcausse>	 I don't have strong opinions, page_kind is ok, page_type as well... 
[13:55:27] <ebernhardson>	 will ponder, i didn't understand your comment about fixtures though. They have to change when the mapping changes?
[13:56:23] <dcausse>	 ebernhardson: I think the search fixtures changed and was surprised because you did not change the query (but perhaps I missed something)
[13:56:37] <ebernhardson>	 oh, i thought i only changed the mapping fixtures. lemme check
[13:57:11] <ebernhardson>	 dcausse: oh! indeed, those must_not's go with the filter
[14:08:32] <dcausse>	 12m46 for tests to pass on an empty db, 10m with a prepopulated index, 27m for the two passes on 2 opensearch image... getting close to the previous timing with a single image
[14:08:42] <ebernhardson>	 nice!
[14:08:50] <ebernhardson>	 thats progress for sure
[14:09:11] <dcausse>	 issue is there are some warnings about duplicated files we upload on the second run
[14:09:28] <dcausse>	 they don't fail the test but are just a bit noisy in the output
[14:11:35] <dcausse>	 will dig into concurrent runs
[14:27:00] <dcausse>	 some tags are timing out... "Error: Timed out waiting for [uploadOverwrite:Linux_Distribution_Timeline_text_version.pdf]" might be tedious to get right :/
[14:33:20] <ebernhardson>	 yea, those are the ones i just kept adding more to the timeout because i don't really know what else to do
[14:35:34] <dcausse>	 I guess it's going through ghostscript or the like?
[14:38:41] <ebernhardson>	 pdf's do yea
[14:39:22] <ebernhardson>	 i wonder what benefit pdfs bring, maybe there is some other format (plain text/markdown) that we could upload to get file_content instead?
[14:43:27] <dcausse>	 yes... was going to try to replace with very tiny pdf but we could well get the same tests with another text format
[14:44:16] <dcausse>	 haven't looked closely but possibly there are some thumbnails generated
[14:44:50] <ebernhardson>	 yea pretty sure it renders images from the pdf, but not sure when exactly
[14:45:14] <dcausse>	 anyways will continue on that next week, I have to run, have a nice end of the week
[14:45:20] <ebernhardson>	 take care
[14:45:39] * ebernhardson is finally removing groovy from regex keyword
[14:45:58] <ebernhardson>	 i would have to adjust it to handle the redirect scope changes, and fixing that groovy is just silly :P
[16:23:15] <atsukoito>	 ebernhardson, dcausse: I tested this patch for Translate plugin, https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Translate/+/1297694, should be good to go
[16:30:58] <ebernhardson>	 lookig
[16:33:00] <ebernhardson>	 yea that should be fine, in cirrus we went with turning integers into an empty range (2-2), but this will work as well. 
[17:00:10] <atsukoito>	 ebernhardson: thanks!
[18:37:00] <pfischer>	 ebernhardson: o/ are you around for our 1:1?
[18:40:05] <ebernhardson>	 pfischer: doh, yes!
[20:02:06] <pfischer>	 Since we discussed online courses, here's a recommendation from Xabriel, just in case you missed it: https://wikimedia.enterprise.slack.com/archives/C02291Z9YQY/p1780082545714109
[20:16:17] <ebernhardson>	 always awkward decisions to make...one the one hand it seems like forcesearchindex should work a row at a time, at least in the normal case. But when used for backfilling (not at wmf) it should probably behave the same way as the realtime updates would, and update both the redirect doc and the target (for the redir array)
[21:16:16] <Trey314159>	 I found an infinite did-you-mean chain on enwiki. Searching for михаил ("mikhail") gives "Did you mean: михайл"; searching for михайл gives "Did you mean: михаил". Since we ignore the difference between и and й on enwiki, they give the exact same 2,790 results, too—though ranked a little differently.
[21:24:01] <ebernhardson>	 huh, that is curious