Fri, Feb 16
So, it looks like we cannot record the text of the edit conflict in event logging, at least not with the default auto created schema, as there is a limit (varchar(1024))...
Interesting, so there is https://meta.wikimedia.org/wiki/Schema:EditConflict and the log table for that schema seems to have many more entries than the TwoColConflict log table.
Thu, Feb 15
Looking at https://gerrit.wikimedia.org/r/#/c/406250/5/VisualEditor.hooks.php this might need 1 more config change to enable it on a wiki.
From the logging that has been added:
Per comments in T177599
@Lea_Lacroix_WMDE bump, wondering if you have time to have another look at this one and see if it is still valid?
After the next edit / page purge the links should appear now.
Is ti possible that el.wiktionary lacks «something» in software that «exposes» their data to Wikidata?
Many revision comparisons simply return a prima facie error code ("There is no revision with ID...).
This warning is new as of the Revision refactoring at the start of this year.
Wed, Feb 14
Tue, Feb 13
Does this clear things up? @Addshore
Se we also have this message key for RevisionSlider https://github.com/wikimedia/mediawiki-extensions-RevisionSlider/blob/master/extension.json#L13 and a provided en name https://github.com/wikimedia/mediawiki-extensions-RevisionSlider/blob/master/extension.json#L2
This is the same situation as FileImporter
Experiment @ https://gerrit.wikimedia.org/r/#/c/363321/
The api does give us the following:
We could one day maybe use https://www.mediawiki.org/wiki/Multi-Content_Revisions/Transaction_Management
It looks like this is still happening, tested on https://test.wikimedia.beta.wmflabs.org/wiki/Special:ImportFile
So AbuseFilter serializes a revision object and saves it to the text table.
This is retrieved in AbuseFilter::loadVarDump which is in the stacktrace above, so the unserialization obviously breaks (line 1379 of AbuseFilter.class.php)
I looked through logstash and it looks like this has been happening for some time (since 1.31 wmf16)
Mon, Feb 12
So if something currently goes wrong we already have more information that is provided in that mock, as the mock doesn't include the error message that is returned from the failed import which would provide the user with extra context.
This error message could be something such as:
- Failed to get wikipedia to create import edit with page id: 123
- Failed to create import revision
- Failed to create user edit
- Failed to prepare operations
I think we should get some solid numbers to back up our proposed rate limits.
So the merging of the above patch and closing of T132564 should see watchlist clearing using the job queue enabled with the next train.
Also: the pop ups should show up one after the other with a "1/3" in brackets after headline. so people know how much more to expect. "Conflicting Versions (1/3)", "Choose a base version (2/3)", "Highlighted Text (3/3)"
As a 'third party user' I have no real preference for the location, as long as it is installable via composer.