Closed Bug 871834 Opened 13 years ago Closed 12 years ago

Don't list apps which failed installation under "My Apps"

Categories

(Marketplace Graveyard :: API, defect, P1)

Product:
Marketplace Graveyard
Component:
API
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
2013-05-23

People

(Reporter: krupa.mozbugs, Assigned: andy+bugzilla)

References

Details

(Whiteboard: [fireplace])

steps to reproduce: 1. Log into your marketplace-dev app your Firefox OS phone 2. Try to install Twitter app 3. Currently the install fails with a 500 4. Navigate to "My Apps" expected behavior: Apps which failed installation are not listed under "My apps" observed behavior: Twitter is listed under "My Apps"
The API is failing, but the API is also not atomic. The failure is occurring after the app has already been registered as installed. There is no way for us to make this work, methinks. I'll let the API folks reopen this if they think that they can wrap the receipt endpoint in a transaction or something equally creative.
Status: NEW → RESOLVED
Closed: 13 years ago
Component: Consumer Pages → API
Resolution: --- → WONTFIX
If you cancel app installation, don't we also record an install? (See bug 740269.) That seems more common to me than a 500. All that aside, I'm confused what the problem is here. You installed an app. And it's listed in "My Apps." What exactly happened that made it apparent to you that it failed with a 500? To an average user, did everything look normal?
I've reproduced this: 1. You click install 2. You get a notification saying "Installation failed, server error" or something like that 3. It still shows up under My Apps The API is doing its job but failing when it goes to render the response. But yes, if we did what's in bug 740269, this wouldn't be an issue.
Its failing at the point of the server or client? There was an issue yesterday that I fixed with the server (I believe) with a race condition between master and slave. However I think there's also a double transaction issue which I can clean up. If its happening on the client, there's not much we can do unless we get that notification.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
QA Contact: amckay
Target Milestone: --- → 2013-05-16
Moved Installing out of the second transaction. If there's some other specific errors, please let me know and I'll fix. https://github.com/mozilla/zamboni/commit/d92b1f
Marking resolved for Mr. Mckay.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
NB: this fix potentially caused #873280
A reversion of this commit fixed #873280, so I'm going to reopen this for further consideration. https://github.com/mozilla/zamboni/commit/9f864efa1b87ca75ca4c9d8dd9a3e63416bd863f#mkt/receipts
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Thanks for spotting that, read through https://code.djangoproject.com/ticket/13906 more and I remember the issue. Yeah, will need to find a better option to this. Maybe if the rest of the view fails, manually delete the Installed row, if it was created that time (but not if it already existed).
Target Milestone: 2013-05-16 → ---
Assignee: nobody → amckay
Priority: -- → P1
Target Milestone: --- → 2013-05-23
https://github.com/mozilla/zamboni/commit/80fbf3
Status: REOPENED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.