AMO Manager: Multiple requests for recommended list on first opening

VERIFIED FIXED in mozilla1.9beta5

Status

()

Toolkit
Add-ons Manager
P2
normal
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: morgamic, Assigned: mossop)

Tracking

Trunk
mozilla1.9beta5
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

10 years ago
Steps to reproduce:
1) open add-ons manager for the first time
2) go to get add-ons tab
3) watch http traffic

The service URL seems to be requested multiple times (often 6, sometimes more):
https://services.addons.mozilla.org/en-US/firefox/api/list/featured/all/10

Image here:
http://people.mozilla.com/~morgamic/samo_requests.png

Had 3 people report same thing, so marking NEW -- could someone take a look?  This could be important for AMO scalability if it is indeed sending multiple requests.

Less of a problem if bug 415277 could be fixed, but a separate issue nonetheless.
I'm not totally convinced this is happening, but I agree that I see the same results as you using the tamper data extension (which is not marked compatible with ff3...).

To reproduce my reason for doubting:

1) open add-ons manager, get recommended list
2) close add-ons manager
3) re-open add-ons manager.  list is loaded from cache.

On step 3, tamper data shows me X amount of requests (where X is apparently random but less than 10), but tcpdump shows no packets going to AMO.  On initial startup and when I do a search tcpdump does show the packets.  It seems like tamperdata is malfunctioning to me.
(Assignee)

Comment 2

10 years ago
It is happening because I wrote it to happen. The goal is to find 5 displayable items. So the feature requests 10 in the hope that 5 in there will be suitable (finger in the air generated number). If it doesn't find 5 items it requests another 10 from the recommended list. It keeps doing this until it stops finding new items to display.

This was all written when I was of the impression that the recommended list would spit out random results for each call. In actual fact it is cached so we should be seeing the same list each time. Because of this we could just drop the additional calls and give up after the first request. The hope was that once extensions were updated to Firefox 3 no more than one request would be needed anyway.
OS: Mac OS X → All
Hardware: Macintosh → All
(Reporter)

Comment 3

10 years ago
What if you passed client and version info to the API so the API could only return compatible add-ons?  It would make a more complex query but you'd only have to do it once.  Other services pass more info for that reason (extension updates, AUS, etc.).  Is that plausible?
(Assignee)

Comment 4

10 years ago
I already am passing the client name but version is certainly possible, it should just be a pref change. The other things that we filter on are OS (which we could pass as well) and then we filter out sandboxed items and items that the user already has installed (the last of these we would always have to do client side).
(Reporter)

Comment 5

10 years ago
In cases like this with in-client URLs we've always erred on the side of passing more info than less, so I would be for adding additional info if it helps reduce the # of requests and the ambiguity of API results.  Laura -- what do you think?
Blocking until we can determine if this is accidentally overloading our servers and ironically preventing us from serving any add-ons.
Flags: blocking-firefox3+
(Assignee)

Comment 7

10 years ago
Regardless of whether the repeated calls are overloading the server they are pointless as long as the result is cached so we may as well remove it.

I'd be tempted to up the number of results requested for the one off call to maybe 20, don't know what you think of that morgamic?

Lets do the adjustment to the API taking the app version into account separately.
Assignee: nobody → dtownsend
(Assignee)

Comment 8

10 years ago
Created attachment 303305 [details] [diff] [review]
patch rev 1

Dump the repeated requests, just go with whatever we get first time around.
Attachment #303305 - Flags: review?(robert.bugzilla)
(Assignee)

Updated

10 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 9

10 years ago
Created attachment 305050 [details] [diff] [review]
patch rev 2

This is as the previous patch however it drops the now useless global uri field.
Attachment #303305 - Attachment is obsolete: true
Attachment #305050 - Flags: review?(robert.bugzilla)
Attachment #303305 - Flags: review?(robert.bugzilla)
(Assignee)

Comment 10

10 years ago
Created attachment 305066 [details] [diff] [review]
patch rev 3

Sorry, don't need to track oldcount anymore either.
Attachment #305050 - Attachment is obsolete: true
Attachment #305066 - Flags: review?(robert.bugzilla)
Attachment #305050 - Flags: review?(robert.bugzilla)
(Assignee)

Updated

10 years ago
Whiteboard: [has patch]

Updated

10 years ago
Priority: -- → P2
Whiteboard: [has patch] → [has patch][needs review rstrong]
Attachment #305066 - Flags: review?(robert.bugzilla) → review+
Whiteboard: [has patch][needs review rstrong] → [has patch]
(Assignee)

Updated

10 years ago
Whiteboard: [has patch]
Whiteboard: [has patch]
(Assignee)

Comment 11

10 years ago
Checking in toolkit/mozapps/extensions/src/nsAddonRepository.js;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsAddonRepository.js,v  <--  nsAddonRepository.js
new revision: 1.2; previous revision: 1.1
done
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3 beta5

Comment 12

10 years ago
hi mike, wil,

can you verify this has been fixed in your service URL tool?  Thanks.
(Assignee)

Updated

10 years ago
Whiteboard: [has patch]
(Reporter)

Comment 13

10 years ago
I don't see this issue any more.
(Reporter)

Comment 14

10 years ago
Wil - reopen if you see otherwise.
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.