479638 - Unhiding app update after download started no longer works

Status: RESOLVED WORKSFORME

(Toolkit :: Application Update, defect)

Description

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

I'm seeing very strange behavior when unhiding an app update that was hidden during the download phase. This was working for me a couple of days ago so I suspect something has landed outside of app update that has caused this.

A couple of unusual errors from the error console
AUS:SVC UpdateService:downloadUpdate - no support for downloading more than one update at a time
* it appears that app update thinks there are multiple updates available when there is only one.

AUS:SVC Downloader:onStopRequest - spec: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/02/2009-02-20-10-mozilla-central/firefox-3.2a1pre.en-US.win32.partial.20090220102957-20090221034716.mar, status: 2152398850
* not sure if this was present before but I believe 2152398850 is user canceled.

AUS:SVC Downloader:onStopRequest - non-verification failure

Comment 1

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

Immediately after re-opening the update ui the following is reported with nothing coming after it

AUS:UI gDownloadingPage:onStopRequest - pausing download

It should be resuming the download after this pause

Comment 2

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

I tried
BuildID=20090121071104
SourceStamp=c989bb1f272d

and everything is fine with that build

Comment 3

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

Working Minefield build
BuildID=20090219032045
SourceRepository=http://hg.mozilla.org/mozilla-central
SourceStamp=d9d4bf676f65
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009-02-19-03-mozilla-central/

Regressed Minefield build
BuildID=20090220102957
SourceRepository=http://hg.mozilla.org/mozilla-central
SourceStamp=35d78a340566
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009-02-20-10-mozilla-central/

Pushes during that time
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=34ca825df468&tochange=35d78a340566

Comment 4

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

Not sure which of the landings caused this but the next nightly works properly so resolving -> wfm