The way Commons currently deals with this issue is mention in the appropriate "Public Domain Day" category and categorization of the DR in the appropriate "Undelete in" category (both under Category:Undeletion requests).

@LPfi Thanks for adding this, pursuant to our discussion at https://commons.wikimedia.org/w/index.php?title=Commons_talk:WMF_support_for_Commons/Upload_Wizard_Improvements&diff=prev&oldid=1049884186#Categories'_existence_isn't_rechecked . After creating the category, have you tried partially or completely backing out of your session with the Commons UploadWizard and trying again? The wizard may only be reading the state of the category system once at a particular step, rather than representing it live (which might not be technically feasible). Do you have an example file for which you needed to later add the category you wanted to add in the wizard?

Today, it happened again after a day or so idle, so I decided to try something different. Despite AWB showing that it was already logged in from a day or so ago, I logged it in again with Ctrl+L (using saved password but not bot password, and without closing AWB), and AWB then functioned normally. Does the system somehow "forget" that AWB was logged in, and neglect to tell AWB such that the user is prompted to login again? Perhaps the update to 6.4.0.0 (or forced updates by Windows) masked the problem (because I had to login after update anyway). I am using AWB as JeffGBot on Commons.

Today, it worked again after restarting AWB and my laptop.

Ok, I got some new information while trying to save manually:
The program has encountered the following problem:
Attempted to save a wrong page (Article name: 'File:Ambox move.svg', session page title: '')
Heading: Exception in MainForm.Save
description:

workaround:

OS: Microsoft Windows NT 6.2.9200.0
version: AutoWikiBrowser (6.4.0.0), WikiFunctions (6.4.0.0), revision 12927 (2025-02-19 23:34:07)
net: 4.0.30319.42000
duplicate:
site: https://commons.wikimedia.org

AWBPlugins

This seems to be happening again:
While browsing https://commons.wikimedia.org/wiki/Category:Deletion_requests_-_No_timestamp_given
MediaWiki internal error.

@bvibber The tasks are submitted manually by the users, some of whom are loathe to shell out US$13.99⁠/⁠month for YouTube Premium, plus all the necessary hardware expenditures and learning for conversion to a free format. I wonder if YouTube is paying the MP4 patentholders for use of their patented codec technologies.

See also https://commons.wikimedia.org/w/index.php?title=Commons_talk:Video2commons&diff=prev&oldid=1019257953#Help:Server-side_upload

While going back to https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&curid=751116&action=history after reading the second-latest grouping at https://commons.wikimedia.org/w/index.php?title=Commons%3AVillage_pump&diff=1017157726&oldid=1017056542 , I got:"MediaWiki internal error.

It's responding now.

In T387103#10573896, @Herald wrote:

The Cloud-Services project tag is not intended to have any tasks. Please check the list on https://phabricator.wikimedia.org/project/profile/832/ and replace it with a more specific project tag to this task. Thanks!

The Cloud-Services project tag is not intended to have any tasks. Please check the list on https://phabricator.wikimedia.org/project/profile/832/ and replace it with a more specific project tag to this task. Thanks!

I'm sorry, it appears that particular webm file is corrupt, although my local source mp4 file opens up and plays with MPC-HC just fine. I can't open that webm file locally. I will open files after conversion and before attempting to upload.

In T383554#10473969, @Bawolff wrote:

I don't think its very easy to do a server side upload via a stashed file. You will probably have to upload it somewhere else

Sadly, that stashed file expired. My latest one is https://commons.wikimedia.org/wiki/Special:UploadStash/file/1bidacse1o08.3e3cuf.122116.

Reported there at https://github.com/danmichaelo/croptool/issues/218

The dot at the end of the URL may be important. It shows on my Upload stash page https://commons.wikimedia.org/w/index.php?title=Special:UploadStash&withJS=MediaWiki:EnhancedStash.js but not here. You may also find the wikitext at https://commons.wikimedia.org/w/index.php?title=File_talk%3ADixiana_1930_%28colorized%2C_1437_%C3%97_1080%2C_30FPS%29.webm#Wikitext_for_replacement . The reason I am asking for this is that the chunked upload never finishes - it just keeps assembling for many hours while in the finalize process. I have been documenting my trials and tribulations at https://commons.wikimedia.org/wiki/User_talk:Rillke/bigChunkedUpload.js#Sever-Error_0 .

See also the discussion at The date selected is in the future.

My version of 13:43 seems to have less compression, but Ladsgroup's of 13:33 would be fine, too.

In T380717#10352398, @Reedy wrote:

Probably related to T380174: CloudVPS: IPv6 in eqiad1

@Pokechu22: Commons Filter 303 operates on both anonymous and new users.

See also unactioned issue 320 at https://bitbucket.org/magnusmanske/flickr2commons/issues/320/doesnt-respond .

In T369298#9954690, @Urbanecm_WMF wrote:

Done.

Of course, the more contemporaneous errors continue to be reported on Commons.

I already removed the files, with now 22k pages on my watchlist. Since then, I have only had to back off to 700.

In T363622#9894181, @matej_suchanek wrote:

Something like https://commons.wikimedia.org/wiki/Special:ApiSandbox#action=watch&format=json&unwatch=1&generator=watchlistraw&formatversion=2&gwrnamespace=6&gwrlimit=500 can remove them in batches (of 500).

Thanks @Ladsgroup!

Yes, I have lots of crap on my Commons watchlist, built up over 17+ years. Based on a suggestion at https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump#Low_server_performance? after Special:EditWatchlist failed (see above), I tried to use https://commons.wikimedia.org/wiki/Special:EditWatchlist/raw and got "Not enough memory to open this page". :( How much memory should I need to edit my watchlist with 239k pages? Can someone rid my watchlist of all pages which start "File:" for me?

In T367172#9887919, @GhostInTheMachine wrote:

The status of the user at the moment they made the edit is the correct detail, not the status of the user now.

I had to back off to 100 today, and then I tried to edit my watchlist using https://commons.wikimedia.org/wiki/Special:EditWatchlist and got the following, so it looks like we need "Set $wgShowExceptionDetails = true;" on Commons:
MediaWiki internal error.
Original exception: [f497cc8d-d5a6-4ad1-95eb-db2be5de539e] 2024-06-13 13:19:30: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"
Exception caught inside exception handler.
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

Why is experience level important when displaying watchlist?

In edit https://commons.wikimedia.org/w/index.php?title=File:Queen_Victoria_by_Bassano.jpg&diff=prev&oldid=804669319 Cessy3 vandalistically added en caption "welcome". In edit https://commons.wikimedia.org/w/index.php?title=File:Queen_Victoria_by_Bassano.jpg&diff=prev&oldid=841293383 Haansn08 removed that caption, but earned abuse filter log entries https://commons.wikimedia.org/wiki/Special:AbuseLog/10343284 and https://commons.wikimedia.org/wiki/Special:AbuseLog/10343285 in the process because "New page wikitext, after the edit ($1) (new_wikitext)" is completely wrong (it is not wikitext at all, but a bastardized text representation of the change in wikibase-mediainfo) and triggered Commons Abuse Filter 58. Perhaps we can exclude changes where "New content model ($1) (new_content_model)" is 'wikibase-mediainfo' to remove such false positives?

Here is one of my configurations:

I had to back off to 500, 400, 300, 250, and then 200 today.

In T365154#9855369, @SDudley wrote:

What I end up doing when video2commons doesn't work is that I manually convert to webm on my own device using handbrake. It isn't a full proof alternative, but I guess it can work for a bit.

I had to back off to 400 again today.

In T363622#9750857, @Jeff_G wrote:

This happened intermittently. It didn't happen with suboptimal "limit=500".

In T365154#9809719, @Chicocvenancio wrote:

Clearly V2C is not ready for use, except for beta-testers.

@Yann I'm maintaining this on my free time and have made a grand total of 0 from all this work. This comment, as written, does not motivate me to work on this at all.

I got "An exception occurred: WorkerLostError: b'Worker exited prematurely: signal 15 (SIGTERM) Job: 4.'"

I have also gotten lie "No changes during the given period match these criteria." What can you do to make it faster or increase the timeout? What is the current timeout?

This happened intermittently. It didn't happen with suboptimal "limit=500".

In T295007#9655859, @Joe wrote:

With the API change, you should be able to upload by url large files (up to 4 GB IIRC) without incurring in timeouts; and that will also allow us to move file processing to Shellbox, making our infrastructure more secure.

In T355433#9485168, @MikhasikRV wrote:

In T355433#9484879, @Jeff_G wrote:

I was able to download the file as F 1-74-0217.PDF. In case one of us gets it to upload, what filename would you like and how would you like the file description page to read?

As I said in the other thread, this is not the only file I need to upload. But how did you manage to upload that file? Using Upload Wizard?

In T355433#9482093, @MatthewVernon wrote:

Right, those are all too far ago to still in the recent logs. Today's, however, I can find, and swift has done what was asked of it - that file was uploaded and subsequently deleted (before further requests got 404, which you'd expect after a successful delete).

In T355433#9482231, @MikhasikRV wrote:

@MatthewVernon I just used Upload Wizard to upload the file. I did not see neither attempt to delete the file after upload. After progressbar reached the end, it just spit out the abovementioned error.

You can try to upload the file yourself: https://fex.net/s/ckmb8ov - the same file or any other PDF bigger than 1.5 GB.

In T355433#9482934, @Wilfredor wrote:

I think the simplest way to correct this error is to lower the maximum upload limit to 1 GB for validation.

The thumbnails at https://commons.wikimedia.org/wiki/File:Ada_Health_Symptom_Checker_conceptual_overview.png are still broken. "via cp1111 cp1111, Varnish XID 376415587
Upstream caches: cp1111 int
Error: 500, Internal Server Error at Sat, 30 Dec 2023 11:49:56 GMT"

Another user has gotten "FAILED: stashfailed: Internal error: Server failed to store temporary file." - see edit https://commons.wikimedia.org/w/index.php?title=Commons:Help_desk&diff=prev&oldid=830516577 .

An hour later, it is responding.

See also the edits logged at https://commons.wikimedia.org/w/index.php?title=Special:AbuseLog&wpSearchUser=2605%3ABA00%3A4138%3A445%3A1974%3ACACD%3AE09D%3AA640&offset=&limit=50 and https://commons.wikimedia.org/w/index.php?title=Special:AbuseLog&wpSearchUser=Haansn08 .

See also the edits logged at https://commons.wikimedia.org/w/index.php?title=Special:AbuseLog&wpSearchUser=91.120.252.226 .

The full URLs for those example links are: https://commons.wikimedia.org/wiki/Special:AbuseLog/9710528 , https://commons.wikimedia.org/wiki/Special:AbuseLog/9711367 , and https://commons.wikimedia.org/wiki/Special:AbuseLog/9711938 . See also https://commons.wikimedia.org/wiki/Commons_talk:Abuse_filter#Report_by_Lieven , which will be archived to https://commons.wikimedia.org/wiki/Commons_talk:Abuse_filter/Archive_2023/04#Report_by_Lieven .

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.