In T431668#12103467, @Jdforrester-WMF wrote:

I think the issue is that the on-wiki config set for dewiki conflicts with the code now. Either, if "Revise Tone" is meant to be live on dewiki, then we should enable $wgGEReviseToneSuggestedEditEnabled, or if not, revise-tone should be removed from de.wp's MediaWiki:NewcomerTasks.json (CommunityConfiguration) so it is no longer a configured task type.

One more code from my open tabs if it matters: [e716e06f-d7bd-4e88-ac98-c9408d117a41] 2026-07-09 08:30:58: Fatal exception of type "Error" (from https://de.wikipedia.org/wiki/Wikipedia:Benutzerverifizierung)

In T431668#12103410, @Jdforrester-WMF wrote:

Is this T431625 again?

In T124101#2842864, @MarkTraceur wrote:

I don't see this as "high" priority, but I'm willing to be convinced otherwise. Since these are not current versions of files, it doesn't seem to affect most day-to-day work.

It doesn't seem like these files have anything in common. There are PNGs and JPGs, different file sizes, different resolutions, different upload dates...and different re-upload dates, too. There are even files from at least two different wikis.

Can anyone offer any insight into the similarities between these files?

More missing files:

Well, I managed to do my testing.. by making sure I only used filenames that exist on production.

In T420833#12087356, @Aklapper wrote:

Re-reading what I wrote before, I see that it can be interpreted as passive-aggressive. I apologize.

In T420833#12087315, @Aklapper wrote:

what if you served a small site for just one hour?

Please read the previous answers again.

You could even copy a "this domain is for sale!" page from a domain squatter

Please read the previous answers again.

I can still reproduce this. After overwriting https://test.wikipedia.org/wiki/File:T425216_ESAMS_overwrite_test.png with number 8 it still showed 7. So I overwrite with 9 and it's still 7.

@Jmabel had the same problem! https://commons.wikimedia.org/wiki/Commons%3AHelp_desk#Suggestion_for_mass_rename

In T420833#12082393, @bd808 wrote:

Every existing automation against Beta cluster would fail. Bot wave would probably die off until the next time they come around again.

Could StructuredDataOnCommons help with this?

I can still reproduce this on betacommons.

Initially I had included Wikimedia-production-error but then realized the error isn't uncaught so I removed it, then I was confused because it was still there so I removed it again, then I noticed Herald had reverted me so I reverted myself.

@ABorbaWMF are you sure it was on enwiki? I can only reproduce on enwiktionary: T428574. Should be bad enough though.

In T260286#12032189, @AntiCompositeNumber wrote:

I don't like allowing uploads of image files that we don't thumbnail -- it's a moderation problem. But I definitely agree that spending any developer time on XCF support would be a waste.

In T260286#12030190, @Cparle wrote:

In T260286#10354952, @Bawolff wrote:

Just fyi, here is a perma-link to the discussion on commons https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals/Archive/2020/08#RfC%3A_Deprecate_XCF_file_format . It wasn't a popular proposal.

It didn't have much opposition either - two "oppose" votes, plus the oppose above. There are only ~1700 .xcf files on Commons, afaics it's really not worth spending any effort on keeping it

Found the same on https://commons.wikimedia.org/wiki/File:Semisopochnoi.png:

Camera model	    <span class="plainlinks"><nowiki></nowiki></span>

I'm seeing "Failed to fetch notifications." when I try to view my notifications on enwiktionary, is this related?

I don't know how other users can publish content on this site, though.

In T85838#955840, @Tgr wrote:

This would require adding a new thumbnail parameter to generate "frozen" thumbnails for animgifs, and some way to switch between normal and "frozen" thumbnails.

I wonder what are the reasons for page authors to use animated gifs instead of videos, which seems like a more appropriate technology. Is it just that videos are harder to work with (in which case maybe we should offer automated conversion) or browser compatibility concerns or concerns about the video player UI, or do they actually want the animations to autoplay and loop?

The request was simple. Look in the server logs.

In T425850#11942471, @ssingh wrote:

Can someone confirm on how to reproduce this? If I try to go to Bing and do a reverse search with Commons, it seems to work for me.

https://commons.wikimedia.org/w/index.php?title=Commons:Help_desk&diff=prev&oldid=1216270150 was quite possibly also this. As expected, users get confused.

In T425850#11925597, @Aklapper wrote:

What to look for on Wikimedia's side without knowing the IPs which they use?

In T426373#11924484, @Aklapper wrote:

I don't see how this is related to RestBase? Why were all those folks added as task subscribers?

In T425850#11905943, @Aklapper wrote:

Have you tried to contact Bing why Bing behaves this way?

I just noticed that for https://commons.wikimedia.org/wiki/File:Paul_de_Munnik_(2017).jpg this is messing up MediaViewer for me because the overwrite is a lower resolution (in pixels) than the original (upscaled) file. MV crops the lower part of the image. The difference isn't huge in this particular case so it merely looks odd, but I imagine that when the difference is huge it'll render MV unwatchable.

In T425600#11896993, @Bugreporter2 wrote:

Is it a hoax?

In T425216#11896751, @ssingh wrote:

Yeah, no, I was wrong and I misunderstood the problem. I misread that the actual image also differs across the CDN but it clearly does not.

sukhe@cumin1003:~$ sudo cumin "A:cp and not P{cp2041* or cp2042*} and not A:ulsfo" "curl -s https://upload.wikimedia.org/wikipedia/commons/3/38/Hana_Vagnerov%C3%A1_v_Show_Jana_Krause_19._5._2021_upout%C3%A1vka_10.png | md5sum -"
95 hosts will be targeted:
cp[2043-2058].codfw.wmnet,cp[6001-6016].drmrs.wmnet,cp[1100-1115].eqiad.wmnet,cp[5017-5021,5023-5032].eqsin.wmnet,cp[3066-3081].esams.wmnet,cp[7001-7016].magru.wmnet
OK to proceed on 95 hosts? Enter the number of affected hosts to confirm or "q" to quit: 95
===== NODE GROUP =====                                                                                                                
(95) cp[2043-2058].codfw.wmnet,cp[6001-6016].drmrs.wmnet,cp[1100-1115].eqiad.wmnet,cp[5017-5021,5023-5032].eqsin.wmnet,cp[3066-3081].esams.wmnet,cp[7001-7016].magru.wmnet                                                                                                  
----- OUTPUT for command #1: 'curl -s https://...0.png | md5sum -' -----                                                              
2cb40b6504fc47d19c1989fe8af22152  -

So yeah, I am not sure what is happening here (not that I am the best person for this anyway) but this does not seem to be related to the CDN.

?

I wonder if T420833 was a test run for this.

In T425216#11895597, @ssingh wrote:

In T425216#11887650, @TheDJ wrote:

I believe there is a 24 hourly script that checks cross dc consistency or something

The rather simpler explanation here is the CDN has a hard limit on the cache expiry, which is 24 hours. So what most likely happened here was that the old copy expired in 24 hours itself.

I don't have a good explanation on why this happened but we have seen it happen in the past, very occasionally. Is this still an issue? If yes, we can try to debug it and see if we spot something.

In T425216#11887650, @TheDJ wrote:

I believe there is a 24 hourly script that checks cross dc consistency or something

https://commons.wikimedia.org/wiki/File:Hana_Vagnerov%C3%A1_v_Show_Jana_Krause_19._5._2021_upout%C3%A1vka_10.png and https://commons.wikimedia.org/wiki/File:Mikros_logo.jpeg now show the new revision for me without VPN. Not sure if someone fixed it or if it fixed itself for these files with time. Also unsure if it can still happen again.

It just happened again, this time on https://commons.wikimedia.org/wiki/File:Mikros_logo.jpeg.

In T425216#11883067, @TheDJ wrote:

actually no.. I see the new version just fine. Did you bypass your browser cache ? Because that doesn't get invalidated.