Mon, Jun 17
I assume a mixture of opportunistic (limited row count) purging of rows during existing watchlist row changes along with WHERE clause filtering on SELECT to ignore expired rows would work (e.g. similar to blocks and page protections).
This was likely due to an APC change. Filing a separate task for the 4/20 group 2 regression (which seems out of band for deployments).
Some sort of meeting sounds reasonable.
Sun, Jun 16
Sat, Jun 15
Fri, Jun 14
Thu, Jun 13
I assume the slow part would be $ketama_test( 1e5 ). It could probably use 1e4 if there is a speed problem.
Wed, Jun 12
Fri, Jun 7
This looks OK again.
Thu, Jun 6
This can be done in the Prometheus migration, but it is already available in Hive and turnilo.
Wed, Jun 5
Tue, Jun 4
Sun, Jun 2
Sat, Jun 1
What is the status of this after the above patches are applied?
Fri, May 31
Wed, May 29
Tue, May 28
Thu, May 23
Wed, May 22
Note that the above patches should be live.
Tue, May 21
They preferably would happen in the main DC via POST, but that is not a hard requirement. This is partly why there are WRITE_SYNC and READ_LATEST flags in BagOStuff. A write should work in any DC and will should replicate asynchronously. If the backend supports WRITE_SYNC, then it should make the write best-effort synchronous.
Mon, May 20
What version (or git hash) of MediaWiki are you currently running and do you still have unresolved problems? I've since made patches like 9df277a4ba3b1dc86e11f469d742c3781141da70 and some mediawiki.org documentation changes.
May 16 2019
May 10 2019
May 8 2019
May 7 2019
It's the new use of DeferredUpdates::attemptUpdate/addCallableUpdate in that change instead of plain doUpdate() calls that gives them outer scope.
May 6 2019
May 3 2019
Confirmed via xhgui on page that is known to log "MediaWiki\Revision\RenderedRevision::outputVariesOnRevisionMetaData: Prepared output has vary-revision"
Yes, even Oracle can go under /libs once the foreign key mess is dealt with.
After struggling to reproduce anything, I saw T222431 mentioned the old non-default watchlist (that doesn't use JS). I can reproduce some problems when setting that preference on.
May 1 2019
Apr 30 2019
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/497537/ might fix that (by giving each update it's own transaction round)...but that patch still has some CI issues.
Apr 26 2019
The original cause of this task was deploy related and was probably fixed in d256b472f73956ee8e2503e0254a1107baa1f00a . The later timing increase is probably from something else on-wiki.
Did you try sqlite LCStore (with journal_mode = WAL and synchronous = NORMAL? like the installer uses)?
Apr 25 2019
Right, so this isn't really about LazyImageTransform, but rather than is just one thing used the parsed DOM object. I guess the summary through me off.
Apr 24 2019
What other things are there other than <img> tags? Maybe you could start moving off those things that can be changed to avoid the DOM and document the rest. As I described above, I don't mind hybrid regex/DomElement logic. You could also have a simple state machine that reads the HTML body string, looking for certain tags and when the corresponding terminating tag is found, recording the positions, and using those to get chunk of strings to parse as DOMElements. That would require some assumptions about HTML being balanced/correct (I assume our Parser should handle that already with Tidy/Remex). I'm thinking of something simple kind of like Language::truncateHtml().