log details about every "unexpected" null <updates> that AUS generates (due to frankenfox or otherwise)

NEW
Assigned to

Status

AUS Graveyard
General
11 years ago
10 years ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Assigned: morgamic)

Tracking

4.x (triaged)
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

log details about every "unexpected" null <updates> that AUS generates

right now, by design, I can hit aus with a URL and get a valid, empty <updates> xml data (<updates> </updates>).

In some scenarios, like when you are running the latest release, this is the expected behaviour.

And, there are also work arounds on the AUS side for some client issues, to return empty updates XML data for things like:

https://aus2.mozilla.org/update/2/Firefox/1.5.0.9/....

(because version 2 should not happen for 1.5.0.9, see bug #360127)

But, what about all the other scenarios where http://lxr.mozilla.org/mozilla/source/webtools/aus/xml/index.php generates empty updates?  Could we log all url requests that result in unexpected empty <updates> result, in order to help track down potential issues?
(Assignee)

Comment 1

11 years ago
Yes, we could expand the error detection and log the URL with a reason.  So far there are four cases for no-update:
1. Patch info not found (for explicit channel or fallback channel)
2. Is a nightly and build ID is already latest
3. OS_VERSION is invalid
4. URL is a version 1 with OS_VERSION data (broken profile problem)

Will have to look at where to log it.  I imagine this log might get fairly large.
mike, what about:

4b. URL is version 2 with application version is 1.5? (also, the broken profile problem)
(Assignee)

Comment 3

11 years ago
(In reply to comment #2)
> mike, what about:
> 
> 4b. URL is version 2 with application version is 1.5? (also, the broken profile
> problem)
> 
Yes, that was basically what I was referring to.  That expands it.  I guess it's:
"URL is version 1 with OS_VERSION data and product version is 1.5.*."
Summary: log details about every "unexpected" null <updates> that AUS generates → log details about every "unexpected" null <updates> that AUS generates (due to frankenfox or otherwise)
as it relates to bug #394245, dan points out:

<thunder> interestingly enough, if I replace the extra "/" in your example with %2F
<thunder> I get an error from aus
<thunder> https://aus2.mozilla.org/update/2/Firefox/3.0a8pre/2007082905/WINNT_x86-msvc/en-US/nightly/Windows%2F_NT%205.1/update.xml?force=1
<thunder> possibly aus uses [some of] the fields to look up files on disk?
<thunder> and so you get a 404 when the slashes are correctly escaped

morgamic, are you seeing a bunch of 404s in the AUS logs?
(Assignee)

Comment 5

11 years ago
Looks like it's breaking the apache rewrite somehow:
RewriteRule ^update2/(.*)$ index.php?path=$1 [QSA]
RewriteRule ^update/(.*)$ index.php?path=$1 [QSA]

Will look into 404s and see what causes this 404.  Probably something to do with QSA or auto-decoding in PHP for query string args.
fwiw, upon a 404, the client side will show this in the update ui:

"AUS: Update XML File Not Found (404)"

You need to log in before you can comment on or make changes to this bug.