536395 - Upload failure causes add-on to not appear on dev hub and impossible to upload again with same GUID

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Developer Pages, defect, P2)

Description

[Jorge Villalobos [:jorgev] (he/him)]

Attachment: XPI that triggers the 'null' error

This has been reported multiple times in the past few days, and I was able to reproduce it in preview with the attached XPI.

Steps to reproduce:

1) Download attached XPI and change its GUID.
2) Submit this XPI to preview as a new add-on.
3) In the last step, where the author is informed the add-on is Incomplete, the edit button points to a URL ending in 'null', making it impossible to reach the edit page. Also, the add-on doesn't appear on the Developer Hub.
4) Try to submit the add-on again.
5) You get the "duplicate id" error.

I haven't found a way to figure the add-on ids in order to assign them back to their original authors, so they are all blocked from using them in any way.

Comment 1

[Nick]

I am very much afraid that this problem is caused by the line "<em:homepageURL></em:homepageURL>" in install.rdf. When I removed it, I could do a successful upload.

However, if you changed something in the server software during last 12 hours, the problem might have been fixed without my removal of this line. As I do not know how to DELETE an add-on I have submitted, I do not try to test this system: I could end up with having several tens of needless add-ons.

Comment 2

[u278084]

You cannot delete an add-on you have submitted. However, you are right. It is caused by empty homepageURL.

What happens is that our RDF library inserts a attribute into the empty field. Something like #genid. When we go to save the Add-on, it will fail because we have validation in place to make sure it's a valid url. But, we don't check that it failed. Instead, we continue on our merry way, and set the add-on id to null and continue on like nothing ever happened.

Since I landed myself a big headache trying to figure it out, I might as well get the pleasure of fixing it. It won't be a hard bug to fix.

We should probably ignore empty elements completely. But that requires looking into the RDF code. What I will likely do is send messages back complaining about an invalid homepage, or whatever other attribute can fail.

Comment 3

[Jorge Villalobos [:jorgev] (he/him)]

I'm not familiar with this code, but I think it'd be great that even when unexpected errors like this occur, one of two things happen:
1) The operation is canceled completely and no trace of the add-on remains.
2) The incomplete add-on is created and associated with the author account.

Comment 4

[Bee]

(In reply to comment #3)
> 1) The operation is canceled completely and no trace of the add-on remains.

Yeah!! It would be nice to have a ROLLBACK function!!!!!!!!!!!!!!
Great idea!!!!!!!!! 

Bye!!!!!!!!!!!!!!
Bee!!!!!!!

Comment 5

[u278084]

Attachment: check the return value

This patch fixes it, as well as any other empty tag error (such as invalid e-mail address). It breaks flow a bit, since now it will ask you to re-upload the file after validation is done. But I don't see a better way of doing it.

Comment 6

[Nick]

If everything was OK with my file, if no empty tags were present, then will it ask to upload it again? If not, then this solution is all right.

Comment 7

[Fred Wenzel [:wenzel]]

Comment on attachment 419864 [details] [diff] [review]
check the return value

That works for me, good job.

Comment 8

[Fred Wenzel [:wenzel]]

(In reply to comment #6)
> If everything was OK with my file, if no empty tags were present, then will it
> ask to upload it again? If not, then this solution is all right.

Yes, that's the plan.

Comment 9

[u278084]

In r58934. L10N fixes still need to be checked-in separately.

Comment 10

[Wil Clouser [:clouserw]]

Closing due to comment 9.  Thanks everyone

Comment 13

[Jorge Villalobos [:jorgev] (he/him)]

Reclassifying editor bugs and changing to a new whiteboard flag. Spam, spam, spam, spam...