Closed Bug 1176697 Opened 10 years ago Closed 10 years ago

"Oops! We had an error" when attempting to resubmit an add-on after being deleted

Categories

(addons.mozilla.org Graveyard :: Administration, defect)

Product:
addons.mozilla.org Graveyard
Component:
Administration
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
2015-08

People

(Reporter: cliodice, Assigned: magopian)

References

Details

(Whiteboard: [qa-] Please read comment 38 before posting)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150525141253 Steps to reproduce: With https://bugzilla.mozilla.org/show_bug.cgi?id=1176254 resolved, attempted submission process again. 1. Step 2: Upload your add-on 2. Checked box for unlisted 3. Uploaded xpi with id 9tffxtbr-rsl@free.internetspeedtracker.com 4. Checked Mac OS X and Windows 5. Checked box for manual review 6. Clicked Continue Actual results: Error page for https://addons.mozilla.org/en-US/developers/addon/submit/2 with following messaging. Oops! We had an error. We'll get to fixing that soon. You can try refreshing the page, or head back to the Add-ons homepage. Expected results: Continued to next step in unlisted submission process.
This also happened with userChromeJS@mozdev.org.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think this has happened before with add-ons that were deleted. Both add-ons mentioned in this bug had their listings deleted and are trying to be submitted again. In both cases I removed the add-on ID from the blacklisted guid list, which should be enough to avoid any errors (apparently it isn't). userChromeJS@mozdev.org corresponds to add-on 624470 9tffxtbr-rsl@free.internetspeedtracker.com doesn't appear to match any add-on, so I don't know what the problem is in this case.
Component: Developer Pages → Administration
Wil, we need to figure out what these errors are about and see if we need to delete stale DB entries.
Flags: needinfo?(wclouser)
I'll have to investigate, but I'm pretty sure that just deleting the entries from the blacklist table isn't enough, there's entries in the logs, for example. Last time I tried "deleting an add-on for real" locally, it was so complex that I just gave up. A workaround in the meantime for the poster, would be to upload the add-on using a new guid (if that's possible).
Thanks guys. We confirmed this is isolated to our deleted entry by successfully submitting a different product (1gffxtbr-rsl@www.inboxace.com). Keep us posted on the investigation.
Renaming the emid would require setting up an entirely new project due to how mozdev works. So a new emid is a bit unreasonable. It seems that a clean deletion is sort of basic to implement, and its lack will just continue to cause problems for other such situations.
Yes, changing the ID is rarely convenient for a developer.
It seems like our extension ID gacela2@nurago.com is also affected by this issue.
Jorge, Mathieu, if this bug can't easily be addressed, it is possible to get specific ids cleaned up?
Jorge, Mathieu, has further investigation revealed any new information? Is it possible to get specific ids cleaned up? Thanks.
The amount of developers running into this problem is growing. We need to fix this very soon.
Assignee: nobody → mathieu
Blocks: signed-addons
Severity: normal → critical
Summary: Unlisted add-on Oops! We had an error → "Oops! We had an error" when attempting to resubmit an add-on after being deleted
Here's another add-on with a similar problem: add-on 630300 was partially created with ID "connect@digital-me.nl". The submission process failed halfway and now they can't submit again until we delete that entry.
Hi guys, We're also having the same problem as per 1181007 – extension id is "christo-extension@atlas.lonelyplanet.com"
Just to give you an idea why this problem is very serious for us. The currently blocked id is in use by us for some years now in an addon deployed along with our software. Now we have the requirement to get the extenion reviewed and signed to keep it working in the next version of Firefox. But we are not able to upload the extension to get it signed. And we can not use another id, since then all users of the addon have to enable the "new" addon manually which is, in my opinion, a usability issue. And it would also cause a significant loss of users of our addon.
We're pretty much in the same boat as @devuct. We deploy our addon along with our application and are particularly nervous about the extension signing transition.
:jorgev, I can see such issues in sentry at least as far back as a year and a half ago. Do you think this issue could be that old? Also, it doesn't seem to be linked to the "unlisted" submission, from what i've experimented locally, it does the same for listed add-ons. Do you have more information on that?
Flags: needinfo?(wclouser) → needinfo?(jorge)
From what I can see, the "soft deleted" add-on keeps its GUID (https://github.com/mozilla/olympia/blob/master/apps/addons/models.py#L484-485), but the GUID must be unique, so when submitting the "new" one with the same GUID, obviously it fails (eg http://sentry.mktmon.services.phx1.mozilla.com/mkt/addonsmozillaorg/group/3778/ for an old one, http://sentry.mktmon.services.phx1.mozilla.com/mkt/addonsmozillaorg/group/16211/ for a very recent one). What should I do about that? Should I remove the GUID from the deleted add-on? In which case, keeping it around seems mostly useless. :kmag, thoughts?
Flags: needinfo?(kmaglione+bmo)
(In reply to Mathieu Agopian [:magopian] from comment #17) > :jorgev, I can see such issues in sentry at least as far back as a year and > a half ago. Do you think this issue could be that old? Also, it doesn't seem > to be linked to the "unlisted" submission, from what i've experimented > locally, it does the same for listed add-ons. Do you have more information > on that? Yes, this issue is unrelated to unlisted add-ons and it has happened before. See bug 1146977 for another example.
Flags: needinfo?(jorge)
Well, for one thing, there's a strongly-worded warning, when deleting an add-on, that once it's been deleted, an add-on with the same ID cannot be resubmitted. We're only seeing this error because the GUID blacklist items were deleted, but the previous listings were not. So the clear short term solution is not to delete the blacklist items without also deleting or resurrecting the soft deleted Addon entries.
Flags: needinfo?(kmaglione+bmo)
That doesn't fix the fact that any of these add-ons can't be submitted again (regardless of warning). Either we do a proper deletion (leaving only the blacklisted guid) or we enable some form of undeletion. I would prefer the former, since it used to work that way at least for some add-ons and it's easier from an administration perspective.
Well, you're manually deleting the GUID blacklist item in the admin tools. It's not as though this is something we have actual support for. As long as you're doing an end run around the code this way, you just need to delete the add-on entry the same way.
(In reply to Kris Maglione [:kmag] from comment #22) > Well, you're manually deleting the GUID blacklist item in the admin tools. > It's not as though this is something we have actual support for. It used to work. > As long as > you're doing an end run around the code this way, you just need to delete > the add-on entry the same way. Soft-deleted add-on entries aren't accessible through the admin interface.
PR: https://github.com/mozilla/olympia/pull/612 This allows re-submitting an add-on with the same GUID as a previously (soft) deleted add-on (once its GUID has been removed from the blacklist in the admin). We could go the other route, and making the soft deleted add-ons visible through the admin interface (and in that case, allowing the re-submission of an add-on would imply first removing its guid from the blacklist, and then editing the soft deleted add-on to nullify its guid (or add a suffix or prefix or whatever). If we decide to remove the soft deletion (and delete add-ons for real), please submit a new bug for that.
Please note that if this PR lands, there's really not much (none?) information left in the add-on to find it in the database, and make use of it. From what I can see, the last piece of uniqueness (appart from the id obviously) was the guid. Now that we get rid of it, it's going to be very difficult to select it from the database. I guess we still have the submitted file, and if we want to investigate a dev's history, we could still do so.
Should I file a follow up bug to nullify the guids of all the add-ons being reported on this bug?
If we're indeed going this route (are we waiting for :kmag's approval?), then yes please ;) If we're going down the "remove the soft-deletion", I guess I'll just add a migration to properly delete all the soft deleted add-ons. To be honest, even if we go down the "remove the soft-deletion" route, I'd rather first have this quick fix (nullifying the GUIDs), because I don't know when I'll be able to implement the soft-deletion removal.
Whiteboard: [qa-]
I have also been bitten buy this bug (Duplicate UUID found) - my deleted extension id is nnhgiakjpfnlebaiohamofealpojgjeg@ancho.salsitasoft.com please clear this from the cache/queue
Hi, I also have the same problem – extension id is "firefoxpasswordwarningextension@tu-darmstadt.de" Thanks
Commits pushed to master at https://github.com/mozilla/olympia https://github.com/mozilla/olympia/commit/af445518e3fab2fe2bef0e168136f9f2ea47dcad Nullify the addon guid on soft deletion (bug 1176697) https://github.com/mozilla/olympia/commit/8b70113be5478e60010a8e6f8acbeaa349edb5e8 Merge pull request #612 from magopian/1176697-nullify-addon-guid-soft-delete Nullify the addon guid on soft deletion (bug 1176697)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Hi, my addon also have this problem. "jid1-qQSMEVsYTOjgYA@jetpack". Thx.
Please file a separate bug, attach a copy of the add-on, and explain in detail how you submitted and what happened. Thanks.
However, please wait until Friday and try again, first. This fix won't go live until the end of the week.
Bug 1188607 has the list of IDs to clear up, up to this point. If anyone else has IDs that need to be "undeleted", please include them on that bug if it's still open. Otherwise, file new bugs.
No longer depends on: 1188781
Hi again, So I just tried to resubmit my addon (christo-extension@atlas.lonelyplanet.com) again, it validated as per normal but when I clicked `Continue` from Step 2 (https://addons.mozilla.org/en-US/developers/addon/submit/2) I got an empty response and a blank page. When I tried to reload the page and try again I started getting the Duplicate UUID error once again. Would you be able to clear that ID so I can try again?
I looks like you got this sorted out already. If you (or anyone else) has any problems with deleted / duplicated UUIDs, please email amo-admins AT mozilla DOT org.
Target Milestone: --- → 2015-08
My add-on also has this problem, the ID is: jid0-edalmuivkozlouyij0lpdx548bc@jetpack. Thanks!
(In reply to Ehsan Akhgari (don't ask for review please) from comment #39) > My add-on also has this problem, the ID is: > jid0-edalmuivkozlouyij0lpdx548bc@jetpack. Thanks! The ID is free now. For future requests, please read comment #38.
Failing to Submit Unlisted add-on with error followed by "Duplicate UUID" error Hi, In right of the signing requirements introduced in FF 40, we're trying to submit a new unlisted addon. The first time I was able to upload our add-on and it passed validation checks, but after hitting the submit button I ended up on an error page indicating that some sort of error occurred. So I tried again and now it not passing validation with a "duplicate UUID" error. Our add-on install.rdf file contain the following uuid in under the description tag: kokokaraland@addon.okidokiland.com Can anyone help? Thanks.
(In reply to okidokiland from comment #41) Please send an email to the list mentioned in comment #38.
Whiteboard: [qa-] → [qa-] Please read comment 38 before posting
How long will it take to remove my deleted add-on UUID from your root file/queue after I send the mail to amo-admin@mozilla.org :jorgev
(In reply to muthukumarcse1 from comment #43) > How long will it take to remove my deleted add-on UUID from your root > file/queue after I send the mail to amo-admin@mozilla.org :jorgev I respond to those within the same day, usually.
Thanks for the reply :jorgev.
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.