[04:56:33] !admin Hello. Can you please delete this unused item: https://www.wikidata.org/wiki/Q30542829 [04:56:33] Please visit https://www.wikidata.org/wiki/WD:AN [17:06:06] done [17:22:17] Lucas_WMDE: Hey! If you're still around, do you know if there is any plan on T264283 ? [17:22:17] T264283: Assess cleaning up Wikibase code around CirrusSearch sanitizer job - https://phabricator.wikimedia.org/T264283 [17:22:45] our plan is basically “we’re aware that we should look into this soon” [17:22:50] since the original task was on some backlog [17:23:10] but when we looked at it, it wasn’t clear what exactly would need to be done, so the task was left a bit vague :) [17:26:50] I'm asking because we've had report of broken things in search indices (T264566) that need sanitizer to be properly fixed [17:26:50] T264566: Redirected entity still present in search results after 6 months - https://phabricator.wikimedia.org/T264566 [17:27:05] so maybe we should do another pass on our side to better define what needs to be done [17:28:39] my understanding is a) we should try to turn the sanitizer back on (slowly, per Amir’s comment – for a certain % of edits?) and hope it doesn’t cause excessive DB load; b) per the IRC logs in the task description, maybe we can modify the code so it doesn’t need to render the ParserOutput in the first place, improving the performance not just on Wikidata but everywhere [17:30:05] but I don’t know much about how that would work technically [23:17:21] gehel: yup, one thing is that the sanitizer is hard-coded for general mediawiki installations causing huge spike in load of the term store while it actually doesn't most of those and also from one third up to half of parser cache entries everywhere were because of this. [23:17:54] Turning it back on either should be pretty slow or fixed (which would make it extremely fast too)