[07:04:14] hi dcausse! [07:04:21] atsukoito: hi! [08:15:30] quick errand [09:58:28] lunch [12:50:33] I was up most of the night due to thunderstorms. I'm gonna rest up, should be back in 2-3h [13:00:37] inflatador: ouch sorry to hear this, take care! [13:04:12] \o [13:06:51] o/ [13:21:10] o/ [13:24:05] randomly curious (probably not useful to us): We introduce RankGuard, a decentralized OLTR framework in which users collaboratively train ranking models and exchange model updates directly with other nodes. - https://arxiv.org/pdf/2606.12246 [13:24:21] like a p2p ltr training regimine [13:26:27] (if you favorite a couple papers in google scholar they email about new citations regularly, some are interesting) [13:42:11] interesting, I guess that even if do not do online training we're kind of prone to these attacks if say we decided to ship a new model weekly [13:43:41] yea i suspect the same general idea of poisioning attacks is relevant to us, we just don't have enough automation in there for anyone to see a measurable benefit on a regular timeline [13:44:06] also there probably just isn't *that* much value to adjusting wikipedia full-text search ranking [13:44:41] true, seems like a high effort attack for little gain [13:54:08] hmm, now to figure out where i changed the casing on the Template:foo query... [14:03:23] * ebernhardson of course can't reproduce locally, some combination of wiki configuration likely required.... [14:07:08] ebernhardson: the test failure in MediaSearch? [14:07:35] dcausse: yea, the fail in wikibase mediainfo [14:07:59] i run the test suite against the wikidatawiki in cindy's wiki setup [14:09:51] there's something fishy in our CI, that patch succeeded when I merged it and rapidly broke all CI, re-instatied it via https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/+/1302144 and it's now properly failing... [14:10:30] why did it pass in the first place at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/+/1299604 [14:10:38] indeed :S [14:11:48] I have a pairing session with Antoine on wednesday morning (mainly to discuss T428975) but I'll bring this new problem as well [14:11:49] T428975: LexemeFullTextQueryBuilderTest::testSearchElastic CI test errors - https://phabricator.wikimedia.org/T428975 [14:48:38] hadn't noticed...i did accidentally change the casing in the restore patch when i regenerated the fixtures, maybe my local wgCapitalLinks is set differently, but still doesn't explain how CI passed it... [14:49:02] * ebernhardson would like to disable config inherit for fixture tests...someday [14:50:18] i suppose it's just tedious, not particularly hard. Maybe can have claude pull together a config.json that can be loaded for fixture testing [14:52:31] yes... all fixtures should embark their own config ideally [14:53:01] Will see what claude thinks, what it really depends on i suppose is if we've threaded SearchConfig through everywhere and don't get config through alternate means [14:53:25] i think we've mostly done that, but needs review [16:40:42] * ebernhardson realizes after coming back around and poking at it...this is probably wgCapitalLinks-adjacent, which isn't even referenced in Cirrus anywhere. It implicitly comes in through title handling [17:01:11] dinner [17:03:49] worth a shot, although I admit I wouldn't know how to judge the result differences