[00:13:13] anybody here knows if there's a way to ensure that when I call API on mediawiki server (specifically, wikidata), I do not get a replica with stale data? [00:18:10] SMalyshev, the maxlag param? [00:23:31] Krenair: thanks, reading... [00:24:27] Krenair: hmm I am not sure whether it's what I need.. basically, I know some edit happened recently, and I want to ensure that my call sees that edit. WOuld maxlag do that? [00:24:52] you basically want to force the server to always run against the DB master instead of a replica? [00:25:07] s/always // [00:25:16] I would expect there to be no way to do that [00:25:20] I don't care what the source of the data, I just want it not to give me stale data [00:25:46] Krenair: if you need context, https://phabricator.wikimedia.org/T210901 [00:27:41] hmm I suppose replicas could be slightly behind even if seconds_behind_master is 0, so what you're probably looking for is something to force contacting master [00:28:13] which sounds like a terrible idea to make available for ordinary users [00:31:19] right [00:31:47] I'd probably be ok if the replica would just wait for this edit to be synced, but I am not sure how to tell it that [00:32:14] I do have revision ID, but if the replica is not up to date, it doesn't know when that revision happened... [00:34:17] SMalyshev: you might be able to abuse ChronologyProtector, if you know the master position for the edit [00:34:57] tgr: what's master position? [00:37:02] the DB master position after the edit, which is used by MariaDB for tracking replication progress [00:37:21] tgr: I probably have no way to know that, all I have is revision ID [00:38:17] yeah SMalyshev is looking at this from an API client perspective [00:38:25] normally it gets set as a browser cookie when you make an edit, to avoid you seeing the pre-edit version of the article after the POST-to-GET redirect and freaking out [00:38:46] I don't know if it is exposed to the API [00:38:49] Well I have SpecialPage:EntityData so I could probably put some special code there... [00:38:53] we actually expose that? huh [00:39:11] but on the client side I have just Kafka change stream [00:39:29] so there I get title and revision ID, and that's all [00:40:00] well, you can add it to the event stream if you care enough [00:40:12] so I don't know what happened on edit (and the edit was mostly done by the bot - those are usually most problematic since bots do series of quick edits to same page) [00:40:39] so I have a chance to get not the latest edit but one in the middle when I fetch data from a replica [00:41:50] tgr: hmm... possible. If that helps me... [00:43:13] either make the EventStream hook put that number in the event and make the API accept it (the web interface does both so I don't think it's terribly evil) or add functionality to the API where it can force master based on something like the IP of the request [00:43:41] I doubt we'd want to expose "use master" as a user option, that's like asking to be DoS-ed [00:45:52] yeah that was my thinking too [00:46:06] SMalyshev: OTOH, stale data somewhat depends on your definition [00:46:43] should think hard about exposing that sort of thing even to authorised users [00:47:05] if it's "page A was edited, page B transcludes page A, I want to know if page B shows the updated version of A", I don't think there's a way to get that even directly from PHP [00:49:10] but if the only thing you care about is the replica having the edit, you can just set the ChronologyProtector cookie [00:49:39] which works at a very low level so in theory it should work with the API as well [00:49:47] tgr: well, the definition is "I see rev X edit reported in Kafka, so when I read data from mediawiki I want it to be rev X or later" [00:50:22] tgr: transclusion is irrelevant, it's wikidata [00:50:52] well item labels or whatever the equivalent of tranclusion is there [00:51:08] there's no transclusion there [00:51:24] it's just one giant json blob [00:51:31] (on item pages, of course, which is what I care about) [00:52:19] tgr: so where can I read about ChronologyProtector? [00:53:15] you must be new here [00:53:59] the cookie is called cpPosIndex so grepping for that is probably the fastest way of finding the relevant code [00:54:36] so that cookie works for every request or just for some special ones? [00:56:02] ah I see it's in setup so probably for everything [00:56:23] every request, at a glance [00:56:52] (isn't it fun btw that we have URL handling logic in LBFactory?) [00:58:17] if you want to talk to someone who actually understands that area of code, that would probably be Aaron [00:58:50] Yeah I'll try to ping him too [01:38:27] bd808: I think https://gerrit.wikimedia.org/r/#/c/mediawiki/vagrant/+/467096/ is ready [02:08:00] MaxSem: I get `PHP Fatal error: Uncaught Error: Class 'Memcached' not found in /vagrant/mediawiki/includes/libs/objectcache/MemcachedPeclBagOStuff.php:61`. [02:08:19] MaxSem: Which is… exciting. [09:33:53] what is 'mediawiki.legacy.oldshared' and how is that different from 'mediawiki.legacy.shared' [09:34:28] * This file contains CSS settings common to Wikistandard, Nostalgia and [09:34:28] * CologneBlue, the old pre-Monobook skins [09:34:30] interesting [09:35:12] they have different styles for .autocomment [18:25:44] legoktm: Yet more stuff we should delete. :-(