Closed Bug 825237 Opened 7 years ago Closed 7 years ago
We should not save the ETag if the package is incorrect
Bug 820630 introduced the support of ETag. However, we save the ETag value even if the package is bad. Therefore if there is an ETag, the user can retry the download, and the download will be somewhat applied in an inconsistent way. STR: * go to http://owapps.cloudfoundry.com * install the packaged app => installation stopped, which is expected because the manifest is not right * go to the homescreen and restart the download by pressing the icon => installation sort of finishes. Except the icon is not right, and the app can't be launched Nominating but I don't think it should block v1 because the error is correctly written in the log at the first install. However the fix should be easy (storing the |app.packageEtag| just after |app.appStatus|)
Julien: Can you take this?
Assignee: nobody → felash
blocking-basecamp: ? → +
Yep :) But not before Monday now.
Attachment #696495 - Flags: review?(jonas) → review+
To whoever will check in to other trees, this need to go in aurora and b2g18 as well.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
(In reply to Julien Wajsberg [:julienw] from comment #5) > To whoever will check in to other trees, this need to go in aurora and b2g18 > as well. (FWIW, for bugs marked blocking-basecamp+, I have bug queries to tell me this :)...)
You need to log in before you can comment on or make changes to this bug.