When IA Upload fails, often users get and upload into Commons a running djvu otherwise, and pending upload becomes unuseful and confounding. A flag to suggest removal of pending item could be useful to clear the list, while waiting for needed debugging of the tool.
See too T182778 for a suggestion about debugging some ia-upload failures.
I guess any authenticated user would be able to add the flag (and I guess, also remove it)? That sounds good.
How should the actual deleting of the job happen? We could look up users' permissions on wiki and allow admins to delete jobs (although, we don't currently know *which* Wikisource people are from, so that could be slowish). Although, we do know the language of the job, so perhaps we just allow admins from that language to delete the job? That'd be reasonably quick to find out, I think.
The best IMHO would be, that the flag could be activated only by "ia-upload-sysops" (if they exist...) or by the uploader, like it happens into archive.org items, after a successful OAuth access.
Another clean trick could be, to follow links pointing to Commons, and to delete all queued items where the link points to an existing djvu file.
I think an easier fix for this problem is just to delete anything that's been in the queue for more than a week. Does that sound okay? It can be done in a twice-daily job.
I've merged the above and deployed it to test and prod. Also set up a daily cronjob to run the new prune command.
This should keep the jobqueue smaller, removing dead jobs older than a week.
There's not much to QA here other than to observe that the queue doesn't forever increase in size (as was happening on the old installation).
Looking at the job queue on https://ia-upload.wmcloud.org/, the oldest jobs are from 17th July (7 days ago).