Affects Commons, too. :(

In T327003#8525400, @Ladsgroup wrote:

Wrapping should be fixable but making the link actually work (or any parsing of the wikitext to HTML) is quite hard without making the system vulnerable to Stored XSS attacks. I could use action=parse in the commons API but that wouldn't be useful if there is a template in source. It's a bit tricky to fix this.

This amounts to a request to increase the default $wgMaxArticleSize of 2048 (kilobytes) on production wikis. It was authored Feb 21 2006, 7:55 PM in rSVN13070 by timstarling (now @tstarling). Much has changed in user environments in the 16 years since then.

It happened again with edit https://commons.wikimedia.org/w/index.php?title=Commons:Help_desk&curid=523680&diff=698609678&oldid=698605975 00:49 24 October 2022 EDT -0400 (04:49 24 October 2022 UTC). Note also that there are three other edits to the Commons Help desk that falsely show as "updated since your last visit" too.

Here is how that 05:20, 23 October 2022 EDT -0400 (09:20, 23 October 2022 UTC) edit looks on my watchlist with grouping.

On the third hand, it did not happen with my next edit https://commons.wikimedia.org/w/index.php?title=Commons:Administrators%27_noticeboard/User_problems&diff=698405102&oldid=698403797 .

In T321277#8333277, @matmarex wrote:

Does this happen every time when replying with the reply tool, or just once or twice? And did it ever happen when not using the reply tool?

We couldn't reproduce it, and I noticed that there were recently a few new reports of pages not being marked as read on the watchlist when expected (see the last few comments on T218511). Most likely this is not related to the reply tool, and just a part of that general problem.

Same for en.wikipedia.beta.wmflabs.org.

How can file revisions go missing? Don't we have backups? Why can't we delete a file, even though one or more file revisions is missing? What can we do to prevent file revisions from going missing in the future, and to compensate for their missing status in the present?

On-wiki error report: https://commons.wikimedia.org/w/index.php?title=MediaWiki_talk:Gadget-AjaxQuickDelete.js/auto-errors&diff=prev&oldid=657064030
On-wiki discussion: https://commons.wikimedia.org/w/index.php?title=MediaWiki_talk:Gadget-AjaxQuickDelete.js#Renaming
This has been autoreported 11 times so far on https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-AjaxQuickDelete.js/auto-errors , starting "Wed, 18 May 2022 08:35:19 GMT".

In T288346#7283181, @AntiCompositeNumber wrote:

In T288346#7282921, @Krinkle wrote:

[...]
As such, perhaps it would make sense to codify that in MediaWiki natively that for NS_FILE we don't emit this event and instead assume it to be an upload (manually created pages there are very rare and usually an accident, and for catching/reviewing that we have recent changes already).

Would it be possible to only log filespace creations not associated with uploads? From a user's perspective, this wouldn't be too unexpected, as Special:Newpages already does that in the file namespace.

That would work for me. The consensus has now been archived to c:Commons:Village pump/Archive/2021/07#Page creation logs.

In T12331#7233358, @DonTrung wrote:

Should we create a separate task for Wikidata and Wikimedia Commons?

Another victim, this time at 6MB: https://commons.wikimedia.org/wiki/File:Age_of_sail_.jpg

The third upload attempt (a retry with extra comment) completed.

The status of the checkbox appears to be dimmed only after the attempted upload starts.
I sometimes get sequences like the following, which is also concerning (indicating a stuck status for upwards of 30s):
00995: 11/86> in progress Upload: 100%
01110: 11/86> upload is stuck
01111: 11/86> Connection seems to be okay. Waiting one more time...
01115: 11/86> upload is stuck
01116: 11/86> Connection seems to be okay. Waiting one more time...
01120: 11/86> upload is stuck
01121: 11/86> Connection seems to be okay. Waiting one more time...
01125: 11/86> Chunk uploaded

The second attempt failed with stash 188ub70n674k.lpxppz.122116.webm and the following (trying again with the original formulation):
05171: 86/86> Server error 504 after uploading chunk:
Response: upstream request timeout
05171: 86/86> upload in progress Upload: 100%
05235: FAILED: internal_api_error_DBQueryError: [95e6982b-cd9d-4b4c-a124-ce7a1ca45c8b] Caught exception of type Wikimedia\Rdbms\DBQueryError

I tried to publish the file in my UploadStash anyway using a community tool, it said to try back tomorrow. I also started another upload of the same file with "use stash and async (recommended for large videos and photos)" unchecked, and I will check progress after I sleep.

There are also 1,101 pages in https://commons.wikimedia.org/wiki/Category:User_talk_pages_where_template_include_size_is_exceeded .

See also https://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard#Deletion_requests_issue . That section was archived to https://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/Archive_83#Deletion_requests_issue without further comment. https://commons.wikimedia.org/wiki/Category:Pages_where_template_include_size_is_exceeded stands at 289 pages and rising.

See also https://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/Vandalism/Archive_14#TRANSCODE_STATUS .

Another victim: https://commons.wikimedia.org/wiki/File:Jilemnick%C3%BD_h%C5%99bitov_Jind%C5%99ich_Ambro%C5%BE_n%C3%A1hrobek.jpg

This appears to be happening again with https://commons.wikimedia.org/wiki/File:Standard_Model_of_Elementary_Particles_Euskaraz.jpg - please see https://commons.wikimedia.org/wiki/Commons:Help_desk#An_uploaded_image_can't_be_seen_at_any_given_wiki for details.

No tokens found. :(

Strangely, this is happening with my (proxied) Puffin Browser Pro, but not with Chrome, on the same iPad with the same connection.

In T222445#6162123, @WMDE-Fisch wrote:

@Meno25 @Helmoony @Jeff_G @Slowking4 it would be really great if we got some feedback on the above questions. We currently try to figure out what additional data would be helpful so that the communities can better deal with situations like this. Thanks! :-)

This could be extended to all presentations of video thumbnails. See also https://commons.wikimedia.org/wiki/Commons:Help_desk#Changing_default_thumbnail_for_a_video.

The discussion of the display of https://commons.wikimedia.org/wiki/File:Ambigram_New_York_Rich_Man.png was archived automatically to https://commons.wikimedia.org/wiki/Commons:Help_desk/Archive/2020/02#Thumbnail_doesn%27t_display and now I get the following:
Request from 45.33.139.173 via cp1086 frontend, Varnish XID 520356410
Upstream caches: cp1086 int
Error: 500, Internal Server Error at Sun, 01 Mar 2020 14:32:22 GMT

In T220828#5352582, @whym wrote:

Note to @Jeff_G: you might still see the bug on Commons, but that's expected. It might take some time before I update ArchiverBot@Commons to reflect the bug fix. (Maybe next weekend.)

In T12331#4320973, @kaldari wrote:

This is now live on all the wikis except Wikidata and Commons.

However, as of this diff 07:59, 14 July 2019 (UTC) it is still happening.

In T227420#5317903, @DannyS712 wrote:

@Jeff_G that's because the template is still fully protected. You can only edit pages that are template protected. See the current list.

In T227420#5314732, @Urbanecm wrote:

Deployed.

In T226307#5305835, @MusikAnimal wrote:

We should perhaps show a different error message when this happens.

Yes, please.

As of this diff 07:48, 3 July 2019 (UTC), it is thankfully no longer shuffling parameters on my user talk page on Commons.

It is still happening for me today. In the attached screenshot, I am "User:Jeff G." and my edit of 18:41 (UTC-4, EDT, 22:41 UTC with screenshot taken around 23:00 UTC) should have marked all the previous edits to c:Commons:Help desk as read, but it didn't.

The problematic files included https://commons.wikimedia.org/w/index.php?title=File:Bareg5.jpg , https://commons.wikimedia.org/w/index.php?title=File:Toyota_Bus-Train_01.jpg , and https://commons.wikimedia.org/w/index.php?title=File:Toyota_Bus-Train_02.jpg ; all had to be deleted.

A workaround is to start with [[Special:Log/block]] or https://commons.wikimedia.org/wiki/Special:Log/block instead.

The same goes for https://tools.wmflabs.org/geocommons/ .

In T218511#5048840, @aaron wrote:

In T218511#5040211, @Jeff_G wrote:

In T218511#5034922, @Catrope wrote:

This may have been addressed by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/496563/

Thanks, when might that change go live?

Should be everywhere by now.

I found out in the past couple of days that when I unwatch and then watch a stubborn bolded page, that resolves the symptom for the current revision of that page better (with a higher success rate indistinguishable from 100%) than refreshing and purging. Of course, that is just a workaround and it doesn't scale.

In T218511#5034922, @Catrope wrote:

This may have been addressed by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/496563/

This is also happening on Commons, see https://commons.wikimedia.org/wiki/Commons:Village_pump/Technical#Pages_visited_via_diff_remain_bolded .

See also https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals/Archive/2016/08#Rfc:_Should_we_request_a_configuration_change_to_shut_down_cross-wiki_uploads?.

Another example: https://commons.wikimedia.org/wiki/File:Miguel_Baptista_Benedict.jpg

Can this tool please be configured to not import under 10 bytes file description page revisions, or at least to pad the ones under 10 bytes with spaces or the 10 byte string "Padded4AF4"? Alternatively, can it be configured to back off importation of revisions which fail any AF and import the rest (unless the latest revision fails)?

In T192744#4153059, @Gilles wrote:

As for non-WMF MediaWiki deployments, applying sharpening to PNG thumbnails is easily achieved by a one-liner modification to the MediaWiki code. Someone who needs this could go the extra mile and make it based on a config variable and it would get merged into MediaWiki itself. Just like someone recently made JPG quality configurable.

In T190988#4873910, @Nemo_bis wrote:

In T190988#4755722, @SJu wrote:

The problem is still continuing... I propose to switch cross-wiki uploads off

That's certainly the most sensible thing to do. We don't need this unmaintained piece of software to cause havoc on our projects.

Sometimes, the rotation sought is not around the center point, but around the central vertical or horizontal axis (sometimes called mirroring, flipping, or flopping). This should be doable losslessly. See also c:MediaWiki talk:Gadget-RotateLink.js#Mirroring as Rotation.

More examples: https://commons.wikimedia.org/wiki/File:East_Huntington_Bridge_Looking_Downstream.jpg and https://commons.wikimedia.org/wiki/File:East_Huntington_Looking_Downstream.jpg

In T195515#4370949, @Jeff_G wrote:

This problem also appears to be affecting StalkToy and CrossActivity at https://tools.wmflabs.org/meta/stalktoy/ and https://tools.wmflabs.org/meta/crossactivity/ .

Finding and fixing the problem would be great; automating the restart would be a close second.

In T195515#4306205, @Bstorm wrote:

For page queries, we ended up removing one of the joins (revision, since that was the problematic table due to its size).

Can you try putting it back as a test? How big was it?

This problem also appears to be affecting StalkToy and CrossActivity at https://tools.wmflabs.org/meta/stalktoy/ and https://tools.wmflabs.org/meta/crossactivity/ .

This has been happening on Commons, too. This edit by Bsadowski 1, who has Local user-groups Image reviewers, File movers, Rollbackers and Autoconfirmed users and Global user-group Stewards, appears unpatrolled in my watchlist. As a member of Image reviewers, that user should inherit the Autopatrolled group rights. https://commons.wikimedia.org/wiki/Special:ListGroupRights confirms that five groups have the right "Have one's own edits automatically marked as patrolled (autopatrol)": Image reviewers, Autopatrollers; Bots; Patrollers; and Administrators. See also https://commons.wikimedia.org/wiki/COM:VP#Unpatrolled rollbacks.

I suggest merge with T198449.