[14:59:10] Error 1146: Table 'centralauth.global_edit_count' doesn't exist [14:59:10] Function: MediaWiki\Extension\CentralAuth\User\CentralAuthUser::register [14:59:10] Query: INSERT INTO `global_edit_count` (gec_user,gec_count) VALUES (1,0) [14:59:11] wheee [14:59:16] (need to create it manually) [15:04:27] and various other schema changes missing [15:04:30] * Reedy disables CA [17:08:17] Reedy: hm.. you reckon that's a new issue? (i.e. it's been undefined longer for you locally but used to not cause an error when CE is enabled?) [17:08:43] I don't often create accounts on my dev wiki [17:08:58] In theory, after T348486, global-in-production tables will be managed automatically by the installer/update.php [17:08:58] T348486: Migrate CentralAuth to use a virtual database domain - https://phabricator.wikimedia.org/T348486 [17:09:13] I think I recently re-enabled CA due to it being required by some other extension [17:09:36] i was just trying to test a thing related to https://phabricator.wikimedia.org/T348547 and i am very confused. i need you to try to reproduce something for me [17:09:38] we'd no longer "hide" them from extension schema updater hooks etc and instead tell Rdbms if/when a table is meant to be global. [17:10:03] In this case, there's one or more apparently missing schema patches for CA [17:10:07] Which is obviously fun [17:10:09] if you visit here: https://www.mediawiki.org/wiki/Special:ApiSandbox#action=query&format=json&servedby=1&uselang=en&formatversion=2 and click "Make request", do you consistently get "servedby": "mw-api-ext.codfw.………"? [17:10:29] and if you visit here: https://www.mediawiki.org/w/api.php?action=query&format=json&servedby=1&uselang=en&formatversion=2 do you consistently get "servedby": "mw-api-ext.eqiad.………"? [17:10:52] it's fetching from the same URL. why do one kind of requests get routed to codfw, and the other to eqiad? [17:10:55] "servedby": "mw-api-ext.codfw.main-78c65849fb-gsvnm" for the first (20+ clicks, different suffixes obviously) [17:11:07] the second [17:11:07] servedby "mw-api-ext.eqiad.main-786547ddc5-jxccx" [17:11:26] Reedy: afaik CA and other glboal tables have always been manual, on the idea that you don't want them on each wiki, and that's why it has a testing hook to create it there ad-hoc. But that doesn't mean we don't need to create patch.sql files between schema changes. You mean it literally lacks a patch or the patch isn't auto-applied/` [17:11:38] Literally lacks a patch [17:11:49] I obviously knew why they weren't (historically) auto applied :) [17:11:50] all of that should go away after task 348486. Aye, that's pretty bad indeed. [17:12:13] MatmaRex: Special:ApiSandbox does POST requests, and those are routed to the writable core DC (currently codfw) unlike GET requests which are routed to the "closest" core DC [17:12:14] There were some localuser (IIRC) fields missing too [17:13:01] there's probably more cases like that given those tables rarely live long enough anywhere outside prod to outlast a schema change, if they are installed at all outside prod. [17:13:02] taavi: huuuh. [17:15:42] i'll write a patch to change this in ApiSandbox. it seems super confusing for debugging things like this. it definitely super confused me right now. [17:15:49] thanks [18:30:01] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/964963 [20:25:00] MatmaRex: it may be worth involving the API team. Maybe Cc bpirkle or walkthrough the patch at this weeks Code Mob [20:27:47] i could, if anyone would like to hear that