825237 - We should not save the ETag if the package is incorrect

Status: RESOLVED FIXED

(Core Graveyard :: DOM: Apps, defect)

Description

[Julien Wajsberg [:julienw]]

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|)

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Julien: Can you take this?

Comment 2

[Julien Wajsberg [:julienw]]

Yep :) But not before Monday now.

Comment 3

[Julien Wajsberg [:julienw]]

Attachment: patch v1

should be applied after the patch for bug 824695

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

https://hg.mozilla.org/integration/mozilla-inbound/rev/90cd09c695ed

Comment 5

[Julien Wajsberg [:julienw]]

To whoever will check in to other trees, this need to go in aurora and b2g18 as well.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/90cd09c695ed

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/4dd1bf0fef35
https://hg.mozilla.org/releases/mozilla-b2g18/rev/0c64ef06796c

Comment 8

[Ryan VanderMeulen [:RyanVM]]

(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 :)...)