[Wikidata-bugs] [Maniphest] [Commented On] T227758: [investigate] purging strategy

Lucas_Werkmeister_WMDE added a comment. Well, I was more worried that a non-`forcelinkupdate` purge might not update the parser cache. But as far as I can tell: - A regular purge //invalidates// the parser cache. The page will be re-parsed the next time it is requested. (Code can still g

[Wikidata-bugs] [Maniphest] [Commented On] T227758: [investigate] purging strategy

Michael added a comment. In T227758#013 , @Lucas_Werkmeister_WMDE wrote: > I think the `forcelinkupdate` option is just a very confusing name for a fuller purge (I’ll investigate if we need it), but apart from that, yes. https:/

[Wikidata-bugs] [Maniphest] [Commented On] T227758: [investigate] purging strategy

Michael added a comment. So the recommended workflow is: 1. User clicks save button 2. API call to save the change 3. On Success, another API call to purge the page with `action=purge` (and `forcelinkupdate=1` in case the user's edit added or removed links, for example to other items

[Wikidata-bugs] [Maniphest] [Commented On] T227758: [investigate] purging strategy

aaron added a comment. Note that CdnCacheUpdate queues a purge to happen X seconds later to help deal with lag (mediawiki-config has $wgCdnReboundPurgeDelay at 11). If lag gets near that amount, then $wgCdnMaxageLagged will kick in. TASK DETAIL https://phabricator.wikimedia.org/T227758 EM

[Wikidata-bugs] [Maniphest] [Commented On] T227758: [investigate] purging strategy

Michael added a comment. The experience of termbox about parser cache and their ADR could be related? See https://gerrit.wikimedia.org/r/530092 TASK DETAIL https://phabricator.wikimedia.org/T227758 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To:

[Wikidata-bugs] [Maniphest] [Commented On] T227758: [investigate] purging strategy

Lucas_Werkmeister_WMDE added a comment. So if we purge the page via `action=purge` (probably with `forcelinkupdate=1`, though tbh I’m not quite sure what that controls) before reloading it, we shouldn’t have to worry about dispatch lag. That still leaves the issue of replication lag on the r