Also T129845#3351290:
https://upload.wikimedia.org/wikipedia/commons/archive/3/3e/20170615122111%2120170615014039%21Younes.webm publicly visible
https://commons.wikimedia.org/wiki/File:20170615122111!20170615014039!Younes.webm deleted

Can i ask You ? how to delete any file is Dangerous on wikimedia commons ?

Interestingly, I just did https://commons.wikimedia.org/wiki/File:Adsalm.webm?action=purge and now https://upload.wikimedia.org/wikipedia/commons/archive/5/55/20170615014039!Adsalm.webm gives a 404...

In T168002#3356365, @Reedy wrote:

Interestingly, I just did https://commons.wikimedia.org/wiki/File:Adsalm.webm?action=purge and now https://upload.wikimedia.org/wikipedia/commons/archive/5/55/20170615014039!Adsalm.webm gives a 404...

Doesn't seem to work on https://commons.wikimedia.org/wiki/File:20170615122111!20170615014039!Younes.webm?action=purge

Actually, that file belongs to https://commons.wikimedia.org/wiki/File:20170615014039!Younes.webm, and it's gone after the file is undeleted then redeleted

Logs for the bot:
{P5591}

In both cases there are internal_api_error_LocalFileLockError.

Are these files gone now, or is there something still left to do for this specific bug?

Try find out how we are supposed to make sure race conditions will not leave a file on swift? Such fast reuploads & deletes are still happening, and may leave such files anytime.

This phenomenon is similar to T109331 and T133821 to end users that the permanent links remain visible after deletion. The difference is that the linked tickets describe the issue where varnish fails to purge the data and reload from swift, but this one is that the files actually remain on swift (tested with X-Wikimedia-Debug and and adding query parameters; if I'm wrong, please close as duplicate).

The reason why undelete then delete did not help until after purge by Reedy was probably because of the linked tickets.

FWIW the exception on mw side for the file above looks like this (id WUHllwpAAEkAAG5N0gEAAABV)

#0 /srv/mediawiki/php-1.30.0-wmf.5/includes/filerepo/file/LocalFile.php(1753): LocalFile->lock()
#1 /srv/mediawiki/php-1.30.0-wmf.5/includes/FileDeleteForm.php(203): LocalFile->delete(string, boolean, User)
#2 /srv/mediawiki/php-1.30.0-wmf.5/includes/api/ApiDelete.php(164): FileDeleteForm::doDelete(Title, LocalFile, NULL, string, boolean, User, NULL)
#3 /srv/mediawiki/php-1.30.0-wmf.5/includes/api/ApiDelete.php(75): ApiDelete::deleteFile(WikiFilePage, User, NULL, string, boolean, NULL)
#4 /srv/mediawiki/php-1.30.0-wmf.5/includes/api/ApiMain.php(1578): ApiDelete->execute()
#5 /srv/mediawiki/php-1.30.0-wmf.5/includes/api/ApiMain.php(545): ApiMain->executeAction()
#6 /srv/mediawiki/php-1.30.0-wmf.5/includes/api/ApiMain.php(516): ApiMain->executeActionWithErrorHandling()
#7 /srv/mediawiki/php-1.30.0-wmf.5/api.php(83): ApiMain->execute()
#8 /srv/mediawiki/w/api.php(3): include(string)
#9 {main}

Happened again for https://upload.wikimedia.org/wikipedia/commons/archive/8/88/20170617234009!Dfsdfsdfsdfsdf.webm

From @Tbayer's list at Z567, searching for /wikipedia/commons/archive/ shows more:

• https://upload.wikimedia.org/wikipedia/commons/archive/f/f3/20170616101009%21Anthem_of_Europe_%28US_Navy_instrumental_short_version%29.ogg -- false positive, no idea why WP0 users has an interest in it.
• https://upload.wikimedia.org/wikipedia/commons/archive/0/09/20170618024316%21Notepad_to_pc.ogg -- ghost file of a filepage that was deleted on 18th

5+ years later, should we make this public? The issue showed up again in T328875.

I see no particular issue with doing so from a swift POV.

5+ years later, should we make this public?

I don't mind. The WP0 upload abuse the long history now.