833587 - Updating a packaged app to a new version that is too large to fit in the phone fails, but the original packaged app is lost (no longer launches)

Status: VERIFIED FIXED

(Core Graveyard :: DOM: Apps, defect)

Description

[Jason Smith [:jsmith]]

Build: B2G 18 1/22/2013
Device: Unagi

Steps:

1. Install a packaged app that will fit on your phone
2. Update the packaged app on the server to a size that will not fit on your phone. Example below:

{
  "name" : "Test WebAPI Permissions",
  "version" : "1.1",
  "size" :
10000000000000000000000000000000000000000000000000000000000000000000000000,
  "release_notes": "First v1.1 release",
  "icons": {
    "126": "/webapi-permissions-tests/qalogo.png"
  },
  "developer": {
    "name": "Mozilla QA",
    "url": "http://jasondanielsmith.wordpress.com/"
  },
  "package_path":
"/webapi-permissions-tests/simple_packaged_update/state2.zip"
}

3. Check for updates (manual or automatic)
4. Try to apply the update

Expected:

The update should fail with an insufficient storage error thrown.

Actual:

The update fails, but we lose the original old app in the process. This means that you will no longer be able to launch the v1.0 packaged app that was originally installed on the device. If you restart the phone, the app icon switches to a generic, greyed out version. Clicking it allows you to "restart the download." Sounds like what happened here is that we mangled the install failure logic to "restart download" and update logic where we should retain the old app as functional if we fail to download.

Additional Notes:

Definitely a blocker - this is dataloss if you update to an app where you do not have storage to fit the update, as you will lose the original packaged app installed.

Comment 1

[[:fabrice] Fabrice Desré]

Attachment: patch

We were actually not losing data, but we reverted the app installation state to "pending" instead of "installed". With this patch we fail correctly, and keep the app launchable.

There's one remaining issue with gaia that keep prompting for an update, which I don't understand since the state of the app at this point is :

"installState": "installed",
"downloadAvailable": false,
"downloading": false,
"readyToApplyDownload": false,

Julien, can you take a look at the gaia side?

Comment 2

[Fernando Jiménez Moreno [:ferjm]]

Comment on attachment 705148 [details] [diff] [review]
patch

Review of attachment 705148 [details] [diff] [review]:
-----------------------------------------------------------------

r=me

Comment 3

[Julien Wajsberg [:julienw]]

Comment on attachment 705148 [details] [diff] [review]
patch

Review of attachment 705148 [details] [diff] [review]:
-----------------------------------------------------------------

sorry, I can't apply it on a clean b2g18 tree... should I use a mozcentral tree instead ?

Comment 4

[[:fabrice] Fabrice Desré]

This apply on top of 831644 and 832408

Comment 5

[Jason Smith [:jsmith]]

Hmm....does this bug fix a different scenario such as the following?

1. Install a packaged app
2. Update it on the server
3. Check for updates
4. Kill the network connection
5. Try to apply the update

Result - app update fails and the app can no longer be launched. If you restart the phone, the app enters the exact same state described in this bug - it enters the generic icon when clicked, tries to re-download the update.

Comment 6

[Jason Smith [:jsmith]]

Another example scenario:

1. Install a packaged app that's web type
2. Update it on the server to a packaged app that's privileged type non-signed
3. Check for updates
4. Apply the update

Result - same result from comment 5

Which makes me think that this bug is fixing the general error case, right?

Comment 7

[[:fabrice] Fabrice Desré]

(In reply to Jason Smith [:jsmith] from comment #5)
> Hmm....does this bug fix a different scenario such as the following?
> 
> 1. Install a packaged app
> 2. Update it on the server
> 3. Check for updates
> 4. Kill the network connection
> 5. Try to apply the update
> 
> Result - app update fails and the app can no longer be launched. If you
> restart the phone, the app enters the exact same state described in this bug
> - it enters the generic icon when clicked, tries to re-download the update.

With a build from https://tbpl.mozilla.org/?tree=Try&rev=1f047c64e5ce, we fail properly:
the app update fails after the network timeout. We can still launch the app, including after a restart.

Comment 9

[Julien Wajsberg [:julienw]]

(In reply to Fabrice Desré [:fabrice] from comment #1)
> Created attachment 705148 [details] [diff] [review]
> patch
> 
> We were actually not losing data, but we reverted the app installation state
> to "pending" instead of "installed". With this patch we fail correctly, and
> keep the app launchable.
> 
> There's one remaining issue with gaia that keep prompting for an update,
> which I don't understand since the state of the app at this point is :
> 
> "installState": "installed",
> "downloadAvailable": false,
> "downloading": false,
> "readyToApplyDownload": false,
> 
> Julien, can you take a look at the gaia side?

In my testing, I have :

    "downloadAvailable": true,

Which is perfectly normal for me: the update was not downloaded, it's still lying on the server :)

We do catch the error (there is a SystemBanner message that there was an error while downloading the update, and there is the "INSUFFICIENT_STORAGE" message in the log).

So this seems fine to me.

Comment 11

[[:fabrice] Fabrice Desré]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ec3d263e2478

Comment 12

[[:fabrice] Fabrice Desré]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/8ab7e45fc123

Comment 13

[Jason Smith [:jsmith]]

Verified on 1/25 build.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/ec3d263e2478

Comment 15

[Lukas Blakk [:lsblakk] use ?needinfo]

Landed on mozilla-b2g18/gaia master prior to the 1/25 branching to mozilla-b2g18_v1_0_0/v1.0.0, updating status-b2g-v1.0.0 to fixed.