Page MenuHomePhabricator

UploadWizard does not handle 'duplicate-archive' errors correctly
Closed, ResolvedPublic


The image content hash check for previously deleted files is not surfaced correctly through the UI.

Steps to reproduce:

Upload a file that's been previously deleted and proceed through the process

Expected behavior:

Failure on first (upload) step that file with the uploaded contents has been previously deleted.

Actual behavior:

Failure on final (publication) step: "Unknown warning: duplicate-archive"

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 11:47 PM
bzimport added a project: UploadWizard.
bzimport set Reference to bz30625.
bzimport added a subscriber: Unknown Object (MLST).

andreengels wrote:

I got the same problem (with failure "An unknown error occurred.") when uploading a file that, as far as I could see, was not equal to the previously deleted one, but only had the same name.

The reason there is absolutely no indication of what the server would do is because, when UploadWizard passes in the parameter "ignorewarnings", apart from cleverly avoiding name-conflict errors, the API doesn't return any of the warning data.

This patch fixes it:

Once that patch gets accepted and merged, I can throw together a patch to UW that will fix this bug fully. Expect it sometime in the near future.

  • Bug 36150 has been marked as a duplicate of this bug. ***

We had to revert that version as it was a bit janky.

When there are warnings, the 'warnings' object is an object in JSON output, but when there are none it ends up becoming an array.

The additional check for empty warnings then got added to check for a 0 length attribute, which would be the wrong check on an object.

Warnings such as 'bad-prefix' for 'IMG_132483247.JPG' were getting reported, making it impossible to upload files directly from a camera since those warnings were seen as 'unknown-warning'.

There are three new patches for properly dealing with API warnings, one of them to mediawiki/core. This still doesn't fix the root of the issue for this bug (I believe), so again, we need to land these changes before we can seriously address the original issue.

Augh! There needs to be an edit button.

Second patch to UW:

The second patch to UW should deal with _some_ of the problems associated with deleted files, but not all of them. duplicate-archive is, I think, still not dealt with properly, but more testing is needed.

  • Bug 37125 has been marked as a duplicate of this bug. ***
  • Bug 37126 has been marked as a duplicate of this bug. ***
  • Bug 30643 has been marked as a duplicate of this bug. ***


Can someone on the CC list of this bug test again on Commons? One of the patches tied to this bug got merged, and I think the behavior may already be greatly improved. If it works, we can close the bug, if it doesn't, there is another patch sitting in Gerrit that could end this bug's reign of terror.


Created attachment 11004
still a problem

Still can't get past this problem.


Screen_Shot_2012-08-25_at_10.44.43.png (211×913 px, 42 KB)

Wow, there is just a multitude of issues here it seems.

First there seems to be code in the initial upload step to check for duplicates. HOWEVER

1: I suspect the warning is actually encountered in setTransported(), and an error is set, but the logic probably overrides this with setSuccess afterwards. No feedback is ever provided and the upload seems just fine

You'll want something like:
if (warnings.duplicate) (or duplicate-archive)
var dupeFile = warnings.duplicate[0];

"This file is already available as [[File:dupeFile]]." vs. for archived "This file was previously available as [[File:setTransported]]". "Remove upload/Continue"

2: The archive error was not handled in the final step

3: The duplicate errors should be ignored in the final step, just as was-deleted (which means you picked a title that previously has existed).

4: The .showError() of UploadDetails is simply non-recoverable. It does not allow you to remove the file that is problematic, and esp. for unknown errors, that is bad. I should allow you to remove the upload so you can continue the other uploads in your list.

5: The .showError() does not surface the 'Continue' and/or "Upload more files" buttons.

Did this duplicate stuff ever work ?

I doubt it. It seems it is trying to insert a function to create a dialog into the error msg.

I think this might be fixed now in the trunk version. Can someone verify?

Confirmed fixed in master, leaving bug open pending deployment and final verification.

(Small UX issue: The big "Retry uploads" button vs. file-specific override actions are a bit confusing. Maybe clean that up down the road.)

Deployed now as well, works for me.

Gilles raised the priority of this task from High to Unbreak Now!.Dec 4 2014, 10:21 AM
Gilles moved this task from Untriaged to Done on the Multimedia board.
Gilles lowered the priority of this task from Unbreak Now! to High.Dec 4 2014, 11:22 AM