I think that we should try to avoid putting an upper limit on versions a file can have, as our "deletion" tool doesn't actually delete anything.

Are there any reasons we can't just use the same code and logic from bigdelete and DeleteRevisionBatchSize or is move file deletions into bigdelete , either as a slightly renamed copy (eg BigDeleteFiles and DeleteFileRevisionsBatchSize) or just make bigdelete apply to both files and revisions?

I'm unsure as to what would be the cleaner option, but to avoid breaking everything, I think just reusing the bigdelete system again with a new name is probably the best option to avoid breaking anything. (As to policy on how it should be handled, I'm thinking the exact same as normal bigdelete, but Commons is probably the only place where it matters.

As part of my Clinic Duty rotation, I am moving this task to the "Needs Further Discussion" column of our MWI workboard because:

• An internal MediaWiki team member identified the issue.
• The task description gives some insight into a workaround and how much effort this workaround takes.
• I wonder how frequently we are asked to delete files with this many versions.
• I am not sure if this task should go to Radar and be for the MediaWiki Platform team. I have asked in our team Slack channel. I see that Bill completed a related task in 2018.
• I need more context from our team to understand where this task fits in our priorities.

In T425893#11910620, @KineticPelagic wrote:

As part of my Clinic Duty rotation, I am moving this task to the "Needs Further Discussion" column of our MWI workboard because:

• An internal MediaWiki team member identified the issue.
• The task description gives some insight into a workaround and how much effort this workaround takes.
• I wonder how frequently we are asked to delete files with this many versions.
• I am not sure if this task should go to Radar and be for the MediaWiki Platform team. I have asked in our team Slack channel. I see that Bill completed a related task in 2018.
• I need more context from our team to understand where this task fits in our priorities.

Even use case is uncommon, Use job queue for deletion of files with many revisions similar to T198176 is an optimization. We also need to consider undeletion as well, the corresponding task for page (instead of file) is T239095, still open.

Adding to @KineticPelagic 's comment -- could we get a #/% of files that have a number of edits that go beyond the threshold? I agree that we should not necessarily have an upper bound in place, but I would like to get a better sense of how commonly folks are running into this for prioritization purposes.

This may come under Media Platform scope, but I have the same question as @HCoplin-WMF. How common is it for files to have a very large number of revisions?

In T425893#12127484, @JTweed-WMF wrote:

How common is it for files to have a very large number of revisions?

Without looking at any data...I'd say relatively uncommon. However, do note that it's relatively straightforward to create such file (as an attacker), and this task removes the community's ability to handle such a file.

In T425893#12127513, @Urbanecm wrote:

However, do note that it's relatively straightforward to create such file (as an attacker), and this task removes the community's ability to handle such a file.

...and I do think that should compensate the relative uncommonness for priority determination :).

In T425893#11955443, @HCoplin-WMF wrote:

Adding to @KineticPelagic 's comment -- could we get a #/% of files that have a number of edits that go beyond the threshold? I agree that we should not necessarily have an upper bound in place, but I would like to get a better sense of how commonly folks are running into this for prioritization purposes.

I did a query and only 22 files have more than 1000 revisions: