[16:08:31] do we have it documented somewhere why you're not supposed to use RequestContext in ServiceWiring? [16:16:54] MatmaRex: top of ServiceWiring.php, and docs/Injection.md, and as-precedence we have declined T218555 and pending T330109. [16:16:54] T330109: Disallow reference to RequestContext in ServiceWiring - https://phabricator.wikimedia.org/T330109 [16:16:55] T218555: Provide access to WebRequest and associated information via a service object - https://phabricator.wikimedia.org/T218555 [16:17:33] oh neat. thanks [16:20:13] (i'm asking because something is messing up the global state again, and i really want to blame it on that problem, but i don't know the cause yet https://phabricator.wikimedia.org/T343384) [16:21:28] Hm.. yeah, could be. Vector is full of anti-services that cache request state. [16:21:45] but it might also be a case of Parser-induced global state [16:22:28] I'd start by ruling out SpecialPageFactory::capturePath() if you haven't yet. [16:23:18] see also https://phabricator.wikimedia.org/T242835#6064656 [16:23:34] (which Vector basically still implements despite RFC opposition) [16:23:49] yeah i'm looking at that angle right now [16:24:33] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/935921 looks a little suspicious (Special:RecentChanges uses OOUI) [16:41:35] yeah, i'm pretty sure that's the cause. and https://gerrit.wikimedia.org/r/c/mediawiki/core/+/958521 fixes it [16:42:06] (just tried it on the beta cluster) [17:37:21] MatmaRex hm.. strange, why does that change cause RC's call to OOUI to change the global request context value of skin? [17:37:46] I'm guessing IconWidget may be indirectly calling OutputPage::setupOOU() but I see only getters there, no setters [18:09:03] Krinkle: i don't really know, i haven't dug that deep. all i know is that the $this->getOutput()->enableOOUI() call ends up calling RequestContext::getMain() a few levels down [18:09:33] i also don't know which extension/skin is triggering the problem this time, and how. it doesn't happen locally or on patchdemo, but it does on production and beta [18:10:52] but it didn't seem like the details would be very interesting. the basic problem is just "we temporarily change global state, and *something* caches it permanently" [18:11:37] i'm less interested in chasing down all the somethings, and i'd rather change the one place where we mess with the global state (SpecialPageFactory::capturePath) [18:12:35] i tried adding some debug logging there, that's how i found this case. i need to push that patch [18:30:18] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/958540 first offender is Flow ;_; [18:59:52] * Krinkle is reading up on MariaDB 11 https://monty-says.blogspot.com/2022/12/i-want-to-wish-you-happy-new-year-with.html [23:53:01] cwhite: I've tagged T245464 with MediaWiki-libs-Stats. As an excercise, what would be the preferred way for your team to discover this task after such action? Is there a herald rule this tag could be included with? (To manage load, I typically recommend making it a "once" rule, ie.. only after future events and only once per task) [23:53:02] T245464: Use php-hrtime monotonic clock instead of microtime for perf measure in MW - https://phabricator.wikimedia.org/T245464