[16:44:24] as someone still very much getting the hang of how things are done in mw core and in testing, I'd like a little pointer for this https://phabricator.wikimedia.org/T316303#9701656 where a patch is failing CI because with the proposed change, there are a few tests that now would need to be in the Database group. Is it better to just add them to it, or mock out the method that would be invoked, or some other 5thing? [16:44:28] *thing [16:44:45] tgr|away or anyone else who wants to chime in, advice welcome! [16:50:11] apergos: imo the core test can have 'group Database' because it's already an integration/structure test, while CaptchaTest should decide what it wants to be - an integration or an unit test [16:50:23] right now it's a weird mix of both where it tries to mock some dependencies yet accesses global state elsewhere [16:51:03] who would be able to make that decision about CaptchaTest? [16:53:07] mszabo: [16:53:13] I think anyone can do that really - personally, I would consider taking the canSkipCaptcha* tests and putting them into a separate subclass of MediaWikiUnitTestCase because those are trying to be real unit tests where all deps are being mocked [16:53:51] oic [16:54:00] it's already mocking the request and even the config so might as well mock the user, yeah [16:54:28] ok that's really helpful, thanks [16:55:56] yw [16:56:33] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1017486 <- easy php 8.3 fix [16:58:07] mszabo: It's not going to run anyway, because of the setUp? [16:58:27] I mean, yeah, it's better, but... [16:59:47] yeah but setUp is https://phabricator.wikimedia.org/T326386 [17:05:25] TBH, we could probably just vendor the statsd client under includes/stats at this point [17:05:31] *includes/libs/ [17:05:50] I don't expect it to see very active development anyways [17:12:25] well, actually [17:13:46] Is there a nice way to tell ApiBase/Main that we don't care about uselang and to pretend it's set to 'content' not 'user' so we can have our calls cached? At this point I'm looking at over-riding extractRequestParams(!!) just to set it before it's read for the first time and cached for the query lifetime. [17:17:23] uselang=content is not an option for this case? [17:17:58] I don't really want to fix every possible caller around the world to the API, no, I want the API to know that its content doesn't vary by language and cache appropriately. [17:19:04] I guess I could over-ride setCacheMode() itself? Which seems mad but eh. [17:19:26] Oh, no, mCacheMode is still private. [17:19:40] setCacheMode( 'publicnoreally' ); [17:47:53] Filed as https://phabricator.wikimedia.org/T362273 [18:28:40] James_F: does ApiOpenSearch allow cdn caching for logged-in? I vaguely recall yes. How does it do that? [18:29:49] Krinkle: It does; I suppose callers all set a uselang? [18:31:01] But in prod nowadays we call https://en.wikipedia.org/w/rest.php/v1/search/title?q=foo; maybe I should re-write my Action API call to use the REST system instead? [20:52:06] James_F: technically, it's not really possible for an API module to be truly language-independent. What about error handling for example (which isn't necessarily done by the module)? [20:52:23] tgr: We're independent of MW's language handling. [20:52:29] Part of the fun. [20:52:49] or rather, the module can be language independent, but that doesn't make the API endpoint independent. [20:53:20] E.g. what if someone uses assert=bot with that API action? That has a corresponding error message, which is localized. [20:53:36] Yeah, the Action API is generally a poor fit for most things. :-( [20:54:15] Not sure about most things, but for caching it's a very poor fit. [20:54:38] Yeah, but there's no way to extend the new REST APIs AIUI. [20:54:50] Anyway I don't think is possible without patching ApiMain. [20:54:54] * James_F nods. [20:55:37] My API is essentially a batch ?action=raw. [20:55:50] Why not just use a REST API? [20:56:07] Because the REST API doesn't let you do batches. And still isn't officially announced. :-( [20:57:32] It lets you do anything, it's just a PHP file. It doesn't *help* you do batches but then usually it's not super hard to do manually. [20:58:27] ReadingLists had a batch REST API in RESTBase. The MW Interfaces team was planning to migrate it to REST PHP, not sure if it happened in the end. [20:58:31] Oh, right, I meant the existing built-in PageSourceHandler. [20:58:40] granted it wasn't nice to look at. [20:59:17] Is it possible to register new REST handlers in extensions? I thought that was all still paused whilst people continued the arguments about how to name, version, and control the manifests? [21:00:15] It's possible and has been done plenty of times in the last few years. [21:00:24] Aha, https://www.mediawiki.org/wiki/API:REST_API/Extensions seems like it's no longer experimental. [21:00:26] Yeah. [21:42:19] https://gerrit.wikimedia.org/g/mediawiki/core/+/d8e8369c54439b0c49dd66117cddc546b1afe2a3/resources/src/mediawiki.searchSuggest/searchSuggest.js#65 [21:44:00] Not that I can see. Seems there is a way fwiw. OpenSearch is by far is lowest latency and also highest (frontend) traffic action API last I checked so a good example generally (apart from its custom format to unwrap {query} for compat with OpenSearch spec) [21:45:23] James_F: well; vector 22 does indeed. And it's taken quite a perf hit as result. From ~20ms to ~300ms or something. I filed a task when MF started using. [21:45:49] Despite vector 22, OpenSearch is still a lot more traffic atm though. [21:46:33] Also from browser bar, third parties, other skins, and non-v22 wikis. [21:54:16] Ideally I'd like to avoid the huge performance penalty from starting a whole MW stack, but that's unavoidable when asking for MW content blobs. :-) [22:28:37] I know opinions vary, but API shaming about the Action API not doing a thing it was not designed to do and expanding that into a statement that the whole system is bad is pretty lame. [22:31:03] bd808: I spent three hours reading through the git blame of detailed bits of the API to understand why the (very good for the time) decisions made in 2010 and 2015 are breaking my code. I think it's totally reasonable to point out the tensions between back-compatibility and functionality, and how we should steer people to newer, more sustainable stacks instead. [22:32:04] Mostly boiling down to "we built it in 2005, we tried to change it to a better default, said change broke lots of things, so we reverted and hard-coded a previous assumption as unfixable fact"; one person's tech-debt is another person's feature, etc. [22:32:45] "Yeah, the Action API is generally a poor fit for most things. :-(" is not doing the things you just mentioned. It is just being mean to everyone who has put blood and tears into making the world we live in today. [22:33:44] I disagree. [22:34:02] ok.