Closed Bug 317303 Opened 19 years ago Closed 19 years ago

nightly update hangs (20051120->20051121)

Categories

(AUS Graveyard :: General, defect)

x86
All
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 302348
4.x (triaged)

People

(Reporter: Peter6, Assigned: coop)

References

Details

(Keywords: regression)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051121 Firefox/1.5 ID:2005112104

Update channel - "Nightly"

repro
1. Get the 20051120 nightly build.
2. Press Check for Updates.
3. There is an update available -- continue

result: Update spins forever.
there is no way to stop it (closing down doesn't help)

workaround:
close FF
open /update/0/... (any file)
close FF
open FF and see it is still spinning
press check for updates
result... it downloads the full .mar
this still worked in the 20051119->20051120 update
Severity: normal → major
Product: Firefox → AUS
Version: 1.5 Branch → 1.0
Summary: nightly update hangs → nightly update hangs (20051120->20051121)
*** Bug 317305 has been marked as a duplicate of this bug. ***
happens on both Branch and Trunk
Confirmed, when trying to update from Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a1) Gecko/20051120 Firefox/1.6a1 ID:2005112006 it says that no update is found.
I reopened bug 317305 because I'm not entirely sure this is an AUS issue. FYI.
Pacifica(Win32) and Atlantia(OSX) have locked up (both on branch) , but this happened well after release of the nightlies
The staging server ran out of space yesterday, which could account for the 0 byte updates, which might also account for the hangs as well.
I've re-uploaded the full mar files for all three platforms. It will take a little while for these to mirror everywhere.
Assignee: nobody → ccooper
we're not going to get a small .mar for 20051121->20051122 , right ?
I've removed the 0-byte partial update files from the staging server. Hopefully that will generate clean failures/full updates instead of hangs.
Status: NEW → ASSIGNED
Hey, why can't I vote on this bug?  Problem here as well.
The product this bug is filed in (AUS) probably doesn't allow voting (the Bugzilla voting configuration is per-product).
Should someone post a bug about client behavior when a .mar file is not available?    Arguably, the client should fail gracefully when encountering a missing or damaged .mar file.
Bug 302348 sorta covers that, but it needs clarification.
These particular nightly updates (20051120->20051121) aren't going to happen at this point, so I'm duping this under bug 302348 and adding some potential testcases to that bug in the hopes of avoiding future problems.

*** This bug has been marked as a duplicate of 302348 ***
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Depends on: 317623
QA Contact: general → general
You need to log in before you can comment on or make changes to this bug.