333908 - Handle update status 'null' better (or just plain handle it)

Status: RESOLVED DUPLICATE of bug 576939

(Toolkit :: Application Update, defect)

Description

[Jay Patel [:jay]]

Although a successful initial update attempt for 1.5 to 1.5.0.2 works as expected (full mar is downloaded and applied), there are a few cases we have found that break the update system and leave users in a bad state:

Initial update download fails
Steps:
1. Download 1.5 and check for updates
2. While the patch is downloading, shutdown your machine
3. On relaunch, the initial update resumes, but eventually hangs
4. At this point, the update.status is "null", and depending on how far you got with your download, you will either have no .mar file or an incomplete .mar
5. You can no longer check for updates, the dialog opens, but nothing happens...it's in a frozen state.

Forcing a full update by changing update.status to "failed" (after successfully downloading the initial update and choosing to apply later).
Steps:
1. Download 1.5 and check for updates
2. Download the update patch and choose to apply later
3. Shutdown browser and edit the update.status file from "pending" to "failed"
4. At this point, you have a valid complete .mar file, but have told the system that the status is "failed"
5. Relaunch the browser
6. The "full update" dialog opens, but if you try to download the patch nothing happens.  The update system seems to be looking for an update to download, but goes no where.
7. At this point, the old valid complete .mar has been deleted and the update.status is "null"
8. You can no longer check for updates, the dialog opens, but nothing happens...it's in a frozen state.

Both of those cases end up creating a update.status file that is set to "null", which I'm guessing is not handled well by the existing code.  

The only way out of the bad state is to remove updates directory and the active-update.xml file.  Unless someone can come up with a better workaround, we should either hold off on releasing the 1.5 to 1.5.0.2 full update or make sure to release note this.

Comment 1

[Darin Fisher]

-> me

Comment 2

[J. Paul Reed [:preed]]

Darin and I talked, and one workaround for this bug (since it's in client updater code, so a fix for 1.5.0.3 doesn't help until 1.5.0.4) is to publish a complete and "partial" mar that both point to the same complete mar.

This makes the updater happy, despite the fact that they're technically both the same bits.

Comment 3

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I could have sworn we fixed this 'null' case last fall...

In any case, I'll play with this over the weekend.

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

(In reply to comment #3)
> In any case, I'll play with this over the weekend.

... or soon :)

Comment 5

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Jeff, did your patch in 302348 address this issue?

Comment 6

[Jeff Walden [:Waldo]]

(In reply to comment #5)
> Jeff, did your patch in 302348 address this issue?

I haven't tested to see if it did; Adam, do you think you might have time to test this?

Comment 7

[Adam Guthrie]

Can't say I'm seeing the same thing Jay reports:

On the upgrade from 1.5.0.2 to 1.5.0.4:

* If I shutdown Windows during the update, when I restart updates.status is "downloading" and I am able to resume downloading an complete the update.

* If I change updates.status to failed after downloading a complete update, I get a dialog on restart that says downloading the update fails. I am then able to successfully downloading the update and install it.

Using a build with Jeff's patch for bug 302348 in it:

* If I shutdown Windows when it's downloading the update the same thing happens as I mentioned above.

* If I change updates.status to failed after downloading an update when I restart I don't get a software update dialog and going to Help > Check for Updates hangs indefinitely on "Connecting to the update server...".

I'd say as long as the first case works, we're fine. Ben, Jay: either one of you want to verify this is working as stated?

Comment 8

[(not reading, please use [e-mail] instead)]

jay just showed me this bad boy.  yikes.

we have (at least) one way to reproduce it.

this would be good for 1.5.0.11 / 2.0.0.3

Comment 9

[(not reading, please use [e-mail] instead)]

the way we reproduced this was to take 2.0.0.1 -> 2.0.0.2 update, down the partial, make it fail (by putting failed in the update.status) so it got the complete.  then, do the same with the complete.  this lead us to this state.

jay, can you confirm those are the steps?

Comment 10

[(not reading, please use [e-mail] instead)]

sorry for the bug spam, re-assigning bugs back to default owner if I'm not working actively on them.

Comment 11

[Melchert Fruitema]

(In reply to comment #9)
> the way we reproduced this was to take 2.0.0.1 -> 2.0.0.2 update, down the
> partial, make it fail (by putting failed in the update.status) so it got the
> complete.  then, do the same with the complete.  this lead us to this state.

To run this test, I'll need to wait for the availability of the next security update (2.0.0.15).

My Firefox version, at present:
"Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14"

Comment 12

[Robert Strong (they/them - no direct email)]

I'm quite certain that a couple of patches I landed on trunk which also ended up the backport patch in bug 576939 has fixed this. I also verified that everything worked properly using the steps in comment #9. I failed both the partial and the complete using failed: 6 in the update.status after which I got the patch apply failure. After closing the update ui I was able to check for updates and download the update again.

Resolving -> duplicate of bug 576939 since I am too lazy to find the original bugs I fixed this in.